Everybody knows the estimation for tasks, but many folks are still confused on the metric of the estimation.
In waterfall, managers determine a team member’s workload capacity in terms of time. That is, managers estimate how long they anticipate certain tasks will take and then assign work based on that team member’s total available time.
In Scrum, it mentions the team planning meeting before the sprint and one work item of the team planning meeting is requirement break-down and estimation, so after that, we will have the prioritized user story list and story points for each user story.
After the introduction of the most-populated Agile methodology and traditional develop methodology, you may have a question, what is the best metric for task estimation? Story points or hours?
From the neutral point of the view, they both have advantages and disadvantages.
For story points, Scrum does not prescribe a single way for teams to estimate their work. However, it does ask that teams not estimate in terms of time, but, instead, use a more abstracted metric to quantify effort. Common estimating methods include numeric sizing (1 through 10), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL), the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.), and even dog breeds, in which a Chihuahua would represent the smallest stories and a Great Dane the largest. The important thing is that the team shares an understanding of the scale it uses, so that every member of the team is comfortable with the scale’s values. The most-focusing thing is comparison between each user story, larger or smaller, it can’t be affected by a team member’s workload capacity, and the team velocity will be the most-important history data for planning, it will be more accurate than hours; but many folks don’t familiar with the story points and it is more abstract than hours. And usually, the client wants to know when the project will be done before the project kick-off. Using the story points hardly provide it without the history data of team velocity.
For hours, everybody can easily understand that because it is realistic metric. Managers can use it to easily communicate with client about the project planning. But this metric is not accurate enough, why? Usually, the team members are at different levels and everyone has his specialty. A task can be huge if a team member doesn’t familiar with that, it can also be small if a team member is specialist of this task.
From the above, choosing the story points or hours depends on your situation. No matter what you choose, the key point is accurate and easy to understand.
Jack,
The one thing I like to point out with Story Points (or Effort if you are using the MSFT Scrum Process Template for TFS) is that your estimation is based on relative complexity compared to other work items / task / backlog items (choose your poison). Clients usually don’t get this until I explain that developers or PM’s will estimate different length of time(if estimating time) to complete a backlog item because they are typically basing the estimate on if they did the work themselves. But estimating based on relative complexity makes more sense since most of the time multiple developers could be working on backlog items. The hardest thing in starting to effort the items is to figure out what a “Medium” effort looks like, and then base all the other efforts off what is considered “Medium”. Medium may be M, or 13, or Border Collie .
Nice post,
Mike
Hi Mike,
For the “Medium” effort definition, we met this issue before. Usually, we’d like to select one item of what we can finish in two or three days, so we can have some items lower than it and also greater than it.
Another advantage to choose this kind of item is that we can get more accurate status. Compare with the orginal tracking way, we can figure out what we can deliver or not immediately.
The standard could not be changed frequently, because nobody want to change the standard from their mind.
Hope my comment is useful for you and thanks for your reading,
-Jack