I bet our newest devs @andy
and @codeswitch can relate to a lot of this.
We do some estimation, but rarely set deadlines for the exact reasons you outlined. @mscottford
recently offered me and my team a good framework for doing estimations, which was to add a confidence level. "This will take 200 person hours and I'm 33% confident in that" for example.
For sure, I've done some internal estimation and time-boxing of certain tasks and it has helped me a lot. Also, as a new developer and member of the team, it helps me know when to ask for help if I really didn't meet my estimation or I run into a blocker that increases the estimation.
Oh, that percentage of the estimations is a game changer for me. Nice!
Although, in some businesses and some clients, they may not like that approach and I don't know how to dress that up for consumption when they're looking for deadlines no matter what (some have very good reasons!). I would likely look back to scope and what I'm able to do/what my responsibilities are. It's a tough one. Any takers on this question?
I've been taught recently to take it week by week, which has been really helpful and useful for the stress levels. You don't feel like there's a huge mountain in front of you that you have to climb. Some people use sprints for tickets and the like, but I look more at components or features that I can show.
I'm like a scrumban sort of thing? I very much like working at capacity doing more of a kanban style linked to features.
Also, I'm very late to the conversation on this one.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I bet our newest devs @andy and @codeswitch can relate to a lot of this.
We do some estimation, but rarely set deadlines for the exact reasons you outlined. @mscottford recently offered me and my team a good framework for doing estimations, which was to add a confidence level. "This will take 200 person hours and I'm 33% confident in that" for example.
For sure, I've done some internal estimation and time-boxing of certain tasks and it has helped me a lot. Also, as a new developer and member of the team, it helps me know when to ask for help if I really didn't meet my estimation or I run into a blocker that increases the estimation.
This is great advice Ben, I will definitely run @mscottford 's framework by my boss-- it makes a ton of sense! Thanks for reading!
Oh, that percentage of the estimations is a game changer for me. Nice!
Although, in some businesses and some clients, they may not like that approach and I don't know how to dress that up for consumption when they're looking for deadlines no matter what (some have very good reasons!). I would likely look back to scope and what I'm able to do/what my responsibilities are. It's a tough one. Any takers on this question?
I've been taught recently to take it week by week, which has been really helpful and useful for the stress levels. You don't feel like there's a huge mountain in front of you that you have to climb. Some people use sprints for tickets and the like, but I look more at components or features that I can show.
I'm like a scrumban sort of thing? I very much like working at capacity doing more of a kanban style linked to features.
Also, I'm very late to the conversation on this one.