Planning poker for an accurate estimation of the iteration in hours
Hello!
According to the book Agile Estimating and Planning we have - iteration plan estimation and release plan estimation.
Type of items for release plan - user stories estimated in ideal days or points
Type items of iteration plat (sprint ) - tasks estimated in ideal hours
To estimate the backlog items (ideal days or points), he suggests using the method of poker planning, but for assessing the tasks in hours he says that it is useful to estimate collectively and that it should be more accurate in hours. He suggests using note cards for instance. About the use of poker planning for estimating tasks in ideal hours, nothing is said.
In the poker poker there are no certain values - such as 4, 6, 7, 8, 10 and others, which can influence on the accuracy in hours.
Your opinions? Can I use poker planning to precisely estimations of the hours or only for rough story points?
Thank you!
>> Can I use poker planning to precisely estimations of the hours or only for rough story points?
Estimating in hours is difficult and rarely accurate. Humans are better at estimating relative comparisons instead of hours. Planning Poker is typically used in relative estimation (points), not hours, although it can be done. But why bother?
As you have probably noticed, Scrum makes no mention around the techniques to estimate Product Backlog items. Here is what I recommend (as well as others like Mike Cohn):
- For a rough, course grained release estimate I have teams use T shirt sizes and Affinity grouping, and I work with the Product Owner to build a release burn up chart from those T shirt sizes. My teams spend just a few hours at the release level.
- For estimating Product Backlog items (written in the user story format popularized by Ron Jeffries), I recommend using story points. I recommend going no deeper than 2 Sprints, as empericism may give us evidence that we have to change we don't want waste effort.
- The scale I like is the modified fibonacci scale (1, 2, 3, 5, 8, 13, 20...). The reason there are not 4,6,7 etc. as you noted is because we're not looking for perfection. Jeff Sutherland recently blogged about why Fibonacci works so well - google it.
- The tool I like to use for estimation is Planning Poker (uses the New Delphi method). A deck of cards may be used as well.
- For Sprints some teams estimate Sprint Backlog tasks in hours, during Sprint Planning. Some teams use other methods to determine a forecast, such as Velocity, and decide that estimating tasks in hours is a waste of time.
All the best
Chris
Thank you Chris!
"For Sprints some teams estimate Sprint Backlog tasks in hours, during Sprint Planning. Some teams use other methods to determine a forecast, such as Velocity, and decide that estimating tasks in hours is a waste of time"
So, for estimation tasks in ideal hours that is decomposited from stories (Sprint Backlog) your reccomends using Poker Planning /
For example: We have some task : create auth page . And team start to estimate with planning poker using some program on smartphone (unfortunately, we don't have paper cards). eventually after 3 rounds and discussion we got at a common value of task - 5 hours. That is correct?
And team start to estimate with planning poker using some program on smartphone (unfortunately, we don't have paper cards). eventually after 3 rounds and discussion we got at a common value of task - 5 hours. That is correct?
It’s unusual to estimate task hours using planning poker, because the time-scales at task level are generally short enough to allow reasonably accurate forecasting without them.
However, if a team has started to estimate that way, it would be best to allow them to finish. If it proves impractical then they can and should change their method.
If you have concerns, it would be better to ensure that the team are in fact willing and able to inspect and adapt their process based upon such learning experiences. That would be better than trying to identify or prescribe an estimation method up-front.
Thank you!!
What estimation methods or techniques can you recommend for task with hours level ?
>> What estimation methods or techniques can you recommend for task with hours level ?
Andrey - Why are you trying to be so precise? What will estimating tasks in hours return? Do you have any evidence that it will benefit anyone in any way?
Some advice I was given many years ago: Ask the team what they think the best approach should be.
Take note that while Product Backlog Items have an attribute of effort, there is no requirement to estimate work/tasks in hours within the Sprint Backlog. In fact it may even be wasteful to have the team estimate at this level of detail. There are many Scrum teams that relay on past empirical evidence, such as velocity and capacity to determine what to take on in Sprint Planning.
Keep in mind that in Sprint Planning the Development Team self organizes to come up with a forecast - newsflash not a guarantee - and if they find out through empirical evidence that too much was forecasted, they can always renegotiate with the Product Owner.
And if the team decides that putting hours on tasks is beneficial, that's okay. Most teams that do so don't use a tool such as planing poker.
Chris
My team estimates with story points using planning poker. We try to only plan as many story points as we done last sprint. Also, we know how many man-hours last sprint had, so technically we can even say how many hours 1 story point is (in VERY rough average). But we never even bother.
How do you estimate change?
Ich will es auch versuchen