Scrum Methodology

Scrum Effort Estimation and Story Points

Posted by admin under Scrum Basics

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. This is problematic because it does not distinguish between a story that is very hard to complete and one that is undemanding; it only considers how long the work will take. To put it another way, coding a feature and organizing the heaps of documentation on your desk are activities that likely take the same amount of time, but there’s no question that the former would require much more sustained concentration and effort. Because of that fact, they should be recognized as incredibly different tasks, requiring different levels of effort.

Scrum takes a considerably different approach to determining a team member’s capacity. First of all, Scrum assigns work to an entire team, not an individual. Philosophically, this places an emphasis on collective effort. Second, Scrum refuses to quantify work in terms of time because this would undermine the self-organization central to the success of Scrum. This is a major break from waterfall: Instead of a manager estimating time on behalf of other individuals and assigning tasks based on conjecture, team members in Scrum use effort and degree of difficulty to estimate their own work.

What does the process of estimation look like? 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 is uses, so that every member of the team is comfortable with the scale’s values.

In the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on velocity the team’s velocity. This means the Product Owner needs an honest appraisal of how difficult work will be. Thus it is recommended that the Product Owner does not observe the estimation process to avoid pressuring (intentionally or otherwise) a team to reduce its effort estimates and take on more work. Even when the team estimates amongst itself, actions should be taken to reduce influencing how a team estimates. As such, it is recommended that all team members disclose their estimates simultaneously. Because individuals “show their hands” at once, this process is not unlike a game of poker. Unsurprisingly, teams often call estimation “planning poker.” Some teams have even developed their own decks of playing cards expressly for this process.

Still, even when teams possess a shared understanding of their scale, they can’t help but estimate differently. To arrive at a single effort estimation that reflects the entire team’s sense of a story’s difficulty, it often requires numerous rounds of estimation. Veteran teams who are familiar with the process, however, should reach a consensus after just a few rounds of planning poker.