I found days to be the most accurate, because this way, helps understand exactly how particular member of the team performs, and if some task needs to be executed quickly, it can be delegated to other member. Rough estimation in my opinion just helps the team with more relax of the work giving more days, but in the end, each sprint, you have many incomplete stories and reasons for retrospective. We cannot say that Fibonacci method works, it’s really depending on the team.
The interesting thing about "absolute estimates" in say hours is that it is actually a relative estimate of a well known unit...and it's actually measurable after the task is done... Where as it is virtually impossible to accurately measure story points because they are purely based on a made up unit
Thanks so much for the valuable info. Two questions: 1) What if this is a newly formed team and there are no past user stories available for reference. 2) Is there really escaping number or hours of effort, especially when considering capacity planning or roadmap planning?
Hey @gswarriors220! Glad you enjoyed the video. Those are great questions. 1. If it is truly a new team that hasn't worked together then there are two paths to choose from. You could gather user stories from a similar team and have you new team group them by perceived size and then use those as a reference for relative estimation. Or you could just start and after a sprint or two take the completed stories and have the team group them. Either way, you'll be leveraging your retros to evaluation how the team did at estimating. 2. You can definitely escape hours, and that is good because not everyone works at the same speed. It is hard to fully escape numbers. Even when I've worked with teams using t-shirt sizes we would convert them back to number for longer term planning. Numbers are necessary for doing effective calculations.
I found days to be the most accurate, because this way, helps understand exactly how particular member of the team performs, and if some task needs to be executed quickly, it can be delegated to other member. Rough estimation in my opinion just helps the team with more relax of the work giving more days, but in the end, each sprint, you have many incomplete stories and reasons for retrospective. We cannot say that Fibonacci method works, it’s really depending on the team.
The interesting thing about "absolute estimates" in say hours is that it is actually a relative estimate of a well known unit...and it's actually measurable after the task is done... Where as it is virtually impossible to accurately measure story points because they are purely based on a made up unit
Thanks so much for the valuable info. Two questions: 1) What if this is a newly formed team and there are no past user stories available for reference. 2) Is there really escaping number or hours of effort, especially when considering capacity planning or roadmap planning?
Hey @gswarriors220!
Glad you enjoyed the video. Those are great questions.
1. If it is truly a new team that hasn't worked together then there are two paths to choose from. You could gather user stories from a similar team and have you new team group them by perceived size and then use those as a reference for relative estimation. Or you could just start and after a sprint or two take the completed stories and have the team group them. Either way, you'll be leveraging your retros to evaluation how the team did at estimating.
2. You can definitely escape hours, and that is good because not everyone works at the same speed. It is hard to fully escape numbers. Even when I've worked with teams using t-shirt sizes we would convert them back to number for longer term planning. Numbers are necessary for doing effective calculations.
Can you estimate hours based off previous tasks and how long they took?
Can you estimate hours with the Fibonacci sequence or is that not recommended