Story Points Are A Fence!
A recent discussion with a Scrum Master colleague reminded me that conversations are filled with metaphors. Metaphors are used to simplify and represent abstract concepts so they can highlight and or offer a comparison. According to James Geary in his TED talk from July 15, 2010, we use, on average, six metaphors a minute in conversation. We use metaphors because they are useful. Story points are a metaphor. Story points represent a piece of work. In software, a story point is an abstraction used to talk about a piece of functional code that is not perfectly understood. Some pieces of code are harder, bigger, take longer to complete, messier, and might not be as well understood…. the list can go on. That is why story points come in different sizes. Historically two scales have been used. Both scales are based on the Fibonacci sequence. Every person and every team has a different perspective of what story point means because it is a metaphor. However, the understanding generated by the abstraction is enough to allow team members to talk about the functionality or go get a rough approximation of what can be done by the team in a sprint or iteration. Inside the team, the metaphor allows a conversation. Unfortunately, all useful metaphors are used and extended until their marginal utility to facilitate a conversation is reduced to zero (otherwise known as the rule – all good metaphors will be used until they are kicked to death). Story points are no different.
Because the metaphor of story points has been useful, they have been pressed into service for different uses. Examples of uses outside of generating a rough approximation of work that can be accomplished in a sprint, story points are often used for release planning, estimation, measuring teams, and individuals. However, the use of story points as a measure rather than a metaphor is problematic for several reasons.
- Definition – Story points are not a precise definition. Every practitioner crafts their own definition based on what they perceive to be important to getting work done.
- Comparisons require a rosetta stone – In order to understand a story point requires a solid point of context that usually includes working together for some period of time.
- Lack of consistency – A team’s assessment of story points is affected by who has a seat at the table when they are assessed and when they are interpreted.
- Conflating story points and hours – Almost everyone I have ever met has asked the questions, how long, how much or when will I get it when discussing software. Implicit in those questions is the need to estimate. As the metaphor of story points is overused, practitioners often begin to conflate story points with effort hours. A tool designed for rough approximation at the team level is used to precisely estimate a piece of work that is only loosely understood. What could go wrong?
- Story points institutionalize team bias. Teams become consistent in their use of story points when they develop a deep understanding and trust which builds in the team’s shared biases. There is nothing intrinsically wrong with building in the team’s bias, however, that bias makes it impossible to compare teams or to combine story points from other teams to generate precise estimates.
Story points have been a valuable metaphor, unfortunately, that metaphor has been extended to the point where they have lost their usefulness and in some cases are being used in a harmful manner.
Upcoming essays in our upcoming Story Point theme:
Next: Why did we get to this point
Future: A solution and Reforming Story Points