Demystifying Sizing and Story Points
Sizing is one of the key tasks in backlog grooming and Sprint planning meetings, but some teams get bogged down in the numbers. How can the scrum master help? This is our first post in a series on demystifying sizing and story points, by Joyce Carr Schwab, one of Dev Technology’s project managers.
What is sizing?
Sizing is the practice of estimating the overall effort required to complete a backlog item. Effort includes the relative complexity of the backlog item, such as:
Amount of Work:
Web page with 10 fields vs. Web page with 100 fields
Complexity of Work:
Web page with 10 fields that have inter-dependencies vs. Web page with 100 independent fields
Risk or Uncertainty:
- Inherited system with old/brittle code
- Environmental factors
- Interfaces with external systems
- New or untried methodology built from scratch
Who Performs the Work:
Experienced developer familiar with project vs. Junior developer or someone new to the project
So far, this sounds a lot like old-school estimation in terms of hours, right? Yes and no. The difference is that the agile approach aims to free development teams from getting bogged down in estimation paralysis. Estimation is hard. Too often developers feel that their estimates are translated into commitments with hard due dates. Naturally, they become cautious about estimating at all or sandbag estimates to allow time for the unexpected.
Understanding Story Points
Story points attempt to solve this conundrum. The most common story point scale is the Fibonacci Sequence (1, 2, 3, 5, 8, 13). A user story that is 5 story points is more complex than a 3-point story, but there is no other meaning to that number. Points are not hours, dollars, or resources. They combine all the factors listed above in a way that makes sense to the team working on a specific project. Story points represent the team’s best guess about the effort required to complete a backlog item.
If a team gets too wrapped up in the numbers – arguing over the difference between a 5 and an 8 for example – try something simpler, like T-shirt sizes (XS, S, M, L, XL, XXL). T-shirt sizes are further removed from numbers, so they help teams new to sizing avoid thinking of sizing in terms of hours or days of effort. You can also try this fun activity to get your team thinking outside the box.
Teams often size user stories or backlog items before Sprint Planning. All stories in the Sprint backlog must be sized when the Sprint starts. To ensure productive, accurate sizing, the team needs user stories with acceptance criteria.
- Ensure the backlog item or user story has complete acceptance criteria, then review the user story as a team.
- Decompose the user story into sub-tasks, if needed. For example, if the new login screen requires an updated user interface, new database fields, and additional application layer programming, these could be represented as sub-tasks.
- Give the team an opportunity to discuss the story, ask questions of each other and the Product Owner, and even refresh their memories about the relevant code.
- Ask everyone on the team to recommend a size for the story simultaneously.
- If you have agreement, then the size is assigned. If not, continue discussion. After three attempts without agreement, use the larger size.
This post is the first in our series on estimating by Joyce Carr Schwab, one of Dev Technology’s Project Managers. Check out the rest of the series:
Join us at Lean + Agile DC on May 15. Use code DEVTECH15 for 15% off tickets.