Transitioning to Story Points from Man Hours
In a previous article, I wrote about the perils of software project planning using man hours and how story points solve the issue. More about it can be read here:
Man Hour Don’t Work in Software Development
TL;DR: Estimating things in man hours do not work in software development. There are better methologies such as Agile…
In this article, I’ll be describing the difficulty of moving from hour estimates to story points.
Understanding What Story Points Are and Are Not
Story points are an set of increasing numbers based upon the complexity or difficulty of a problem to solve. It’s a scale that is uniquely created by the scrum team and different scrums teams do not need to share the same scale. Examples are:
- Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21
- Linearly increasing by one: 1, 2, 3, 4, 5, 6, 7, 8
- Linearly increasing by a constant number: 5, 10, 15, 20, 25, 30, 35
- Linearly increasing by random: 3, 11, 23, 33, 49, 51
One pitfall to avoid is trying to convert story points back into hour estimates. I have seen teams using 1, 2, 3, and so as story points, but they are converting it back into hours.
“That will take 8 hours… I mean 8 story points.” -Engineer
A fibonacci or random number scale makes it much more difficult to convert back to time units. I recommend using a scale that’s not increasing by a constant number because it forces the team out of converting story points back to time.
A pitfall of teams sharing the same number scale is someone such as a management personnel using it as comparsion of productivity between teams. Team A can accomplish 50 story points but Team B can only 20 story points. The data doesn’t mean that Team A can accomplish 2.5 times the work of Team B because estimations and the user stories completed are different between teams.
The previous example brings up an important issue that story points are not a productivity measure of a person or a team. One other thing I have seen is people trying to measure how many story points each individual has completed over a time period for their performance evaluations. It’s bad performance measurement like measuring a software engineer’s performance by how many key strokes they did in the last month.
Transition to Story Points
How does someone transition from man hours to story points? Let’s use another set of the common estimates, which are t-shirt sizes for projects. Think of story points as t-shirt sizes and user stories as people. People come in all shapes and sizes like a user story. User stories are usually unique and don’t repeat. T-shirt sizes usually come in XXS, XS, S, M, L, XL, XXL. Let’s assign fibonacci numbers to each one: XXS =1, XS = 2, S = 3, M = 5, L = 8, XL = 13, XXL = 21.
The popular way to start using story points is using “planning poker”. Each member of the team gets cards of each of the estimates. The scrum master shows the team a user story and asks them to estimate it by picking a card from their hand but not showing it until everyone has chosen one. Everyone reveals their card when the entire group is ready. Usually a new team will have a wide range of estimates. A common trend for new teams is senior members may estimate the user story lower while junior members estimate higher. A discussion follows about why each member picked their cards.
The process of planning poker is having each member make an estimate that is not affected by another member’s estimate. People’s choices are influenced by other people in what is called herd mentality because no one wants to be the odd person out. However, it’s important to voice concerns and ask questions to gain an understanding why a particular user story is estimated differently because something may have been missed by the other members.
“Everyone is saying 5 so I’ll go with 5 also” — Engineer
One pitfall to avoid is having one person do the estimates because it takes “too long” to have the entire team estimate. The scrum master or a senior engineer making all of the estimates is not how story points work. There needs to be a consensus on the estimates by the entire team. The process takes a while in the beginning but it will decrease over time as the team gets used to making estimates.
For example, a user story can be “As a user, I want to be able to log into the system”. Multiple people estimate a “S” because a 3rd party log in service can be used but one person estimates a “L”. Don’t skip the discussion and estimate it as a “S”, “L”, or take the average as “M”. It’s important to understand the reason why there are two different views on the estimates. The person estimating it as “L” says that not all users will have the 3rd party account and the system needs to support those users as well. This situation can go either way and comes down to the acceptance criteria. Is it acceptable to expect users have a 3rd party account in order to log into the system? Maybe the acceptance criteria didn’t initially address the issue and the product owner will make a call. This discussion has just identified an issue that may have been missed. In a situation where the estimates are close to each other such as “S” and “M”, there isn’t much a difference between the two so choosing the higher “M” is fine.
Data Metric — Team Velocity
Team velocity is how many story points the scrum team accomplishes in a sprint. The assumption is that the team’s velocity will fluctuate up and down like a sine wave but its high and low oscillations will grow smaller over time. A brand new team may have big oscillations in the beginning but it should stabilize as the team members remain static. Over time, the team will establish an average velocity that is a better metric to use to determine how many user stories can be accomplish by that team.
Why does this work? Story point estimates are coming from the team and members of the team do not change. The team should accomplish around story points within the sine wave each sprint. For determining the average, I find that it’s better to use the past 3 month of team velocities than the entire data set. There’s two reasons which are the team velocity in the beginning are usually inaccurate and the team optimizes itself after each sprint.
Using the story point estimates by the team and the average team velocity makes it much easier to forecast what can be accomplish in a sprint. More time is spent on discussing why estimates are different which helps improve the quality of the user story. Less time is spent in trying to loading balance and recalculating individual time estimates.
- Story points have a learning curve
- Story points are a team centric. Time estimates are individual centric.
- Planning poker encourages discussion
- Team velocity will wildly fluctuate up and down in the beginning but will stabilize over time
- Team velocity is needed to forecast how many user stories can be completed in a sprint
Pitfalls to avoid
- Converting story points into time estimates
- Using story points as a measure of productivity of an individual or teams
- Having one person estimate everything
- Changing team members often