I have been involved with Scrum teams for a number of years now and would like to share some tips for teams that have started on their journey with story point estimation.
Why points and not hours?
Traditional project management has led us to believe that there is a magic formula that we apply to estimate a body of work, similar to a chef that always makes that same dish in a restaurant (See Malcolm Gladwell’s TED talk on Spaghetti Sauce). This practice has it’s roots in the industrial revolution where the effort to build like for like widgets using manual human labour can be estimated with great accuracy. The modern knowledge industry has too much variability with respect to the complexity of the work and the skill sets of the workers doing that work.
Estimation in Hours has the following drawbacks:
- Too much selection: Should the work take 40 hours? 42 hours? 44 hours? The team spends a large amount of their time attempting to determine the correct number rather than spending time on productive project work. On top of this, there is an agreement to add a 30 to 50% buffer onto the estimate, “just to be sure”.
- Knowledge work is variable: The team may not have all the information at the beginning of the project when the estimates are being asked. Knowledge tasks vary in their effort due to the unknown information the team has at the time they take on the task. This leads teams to selecting a “best guess” based on untested assumptions or expert opinions that worked well in one project but are not yet validated for the new project.
- Skills of knowledge workers is variable. A developer may be fast when working on UI tasks, but need assistance from an experienced colleague when working with API code. What takes 10 hours of effort for one person may be 40 for another.
I discussed the concepts of Story Points in my LinkedIn article: Agile Story Points, What’s the Point? Which shows that limiting choice and bucketing estimates based on established baselines is a far more productive way to estimate knowledge work.
Choose a Baseline
Take the Fibonacci set of numbers (1, 2, 3, 5, 8, 13, 20). Based on the Definition of Done as agreed to by the team and the sprint cycle length. I recommend 2 weeks for software product development sprints with an estimate that would sit between 8 and 13 being the upper bound for the team to deliver in one sprint*. The team may estimate 13 or higher, however that sends a signal to the product owner that the story must be decomposed further or the team is lacking important information in order to commit to an estimate.
Hold a meeting with all team members. Review tasks that the team has previously completed and write them on index cards. A summary sentence is good enough, the team only needs to remember and recall the effort it took to deliver the task. Do not go into details or into a full retrospective on the task, as those conversations should be held during the sprint review and retrospective.
Write the Fibonacci numbers onto a wall chart ruler (See Figure 1), we will call these “buckets”. The team takes turns placing one of the tasks into a bucket comments on why they are placing it in the bucket. For example, “This was a simple field to add to the form that did not have an impact on any other data in the system, so I’m adding it as a 1”.
The next team member can draw a new index card and place it in a bucket or move an index card from one bucket or another as a part of their turn. If the presenter does not provide a convincing explanation on why the task should go into the bucket then the other team members should challenge the explanation.
Example of a challenge
Member A: “I’m adding this to the 2 point column, because… well, I dunno *shoulder shrug*”
Member B: “What is an example of a 1 point task you have done before and why is this bigger. Also, what might this be smaller than so I can understand why you made it a 2?”
Member A: “Well, it would take me longer than displaying the search results on a page, but not as long as adding a new state in the lifecycle, so I thought it should be a 2.”
Figure 1: Story Point Ruler wall sheet
The team now has a listing of stories, sized relative to each other. During the backlog refinement meeting the team can compare the story sizes on the ruler to the stories they are estimating.
At the end of the sprint, after the stories have been delivered, the team can update the ruler with recent examples to keep the ideas fresh in the team’s mind. Continuously updating the ruler with recently delivered stories keeps newer team members engaged as they gain first hand experience with the delivered stories.
#KnowledgeReducesRisk
* The total of all stories that the team takes on for the sprint. A team that takes on a 3 and 5 point story should be confident to deliver those in a sprint. While a team that takes on a 5 and 8 point story may be at risk for delivering those in a sprint. ScrumMasters and managers should heighten their awareness if the team is pushing for a stretch goal in the latter case. The stories must flow, impediments must be removed!
