Appalling Farrago

This article was originally posted on the thoughtbot blog here

We’ve previously written about estimates when it comes to Why Fixed Bids Are Bad. Today, we’d like to talk about a tool used for estimating that we’ve had little success with.

Story points have become bog standard in our industry to the extent that some teams forget to consider alternatives. The purpose of this post is to discuss the problems story pointing fails to solve and discuss an alternative approach.

Predicting When a Large Body of Work Will Ship

The idea is compelling. Break up the larger body of work into the smallest achievable parts, estimate how long each part will take and the total of those estimates reveals when the work will ship.

Science!

This only works with the following assumptions:

• You know how to break up the work.
• You know how long the pieces of work will take.
• The product priorities will not change while delivering this work.
• It’s more important to know when a feature will ship vs concentrating on shipping the most valuable version of the feature.

Given all the above assumptions, it’s unlikely you can predict a larger body of work with story pointing alone.

An alternative is to start predicting the larger body of work in its entirety and checking in every week. We’ve personally found success with this approach. It forces a re-evaluation of the work each week and allows the team to have meaningful conversations around deadlines, scope and specific technical challenges. These predictions are subject to change and teams are not pressured to give a prediction for work that isn’t predictable e.g. using a new technology.

NOTE: We know in theory story points are an iterative process. In practice, every project we have seen with story points has pointed once and not adjusted later. There have even been times when we’ve acknowledged that work was far more complex than initially anticipated, but the story kept the original estimate anyway. These skills are difficult to master, and the main problem is that simply adding story points gives the impression that estimating is easy!

Tracking Team Velocity and Accountability

Again, on paper, using story points appears to make sense. We would like to have a reliable indicator of the team’s productivity. Measuring productivity allows us to react to impediments before everything grinds to a halt or celebrate increases in productivity and iterate on keeping the team productive.

Unfortunately, this approach suffers from the same fundamental failings as above, in addition to:

• You accurately predicted the “point” cost of the work done.
• You update point cost when the prediction turns out to be inaccurate.
• You never spread work between sprints. (e.g. a ticket’s points are allocated to one sprint but the ticket spanned two or three sprints.)

Story points are often an unreliable data source as the points were collected at a time when the team knows the least about the work. A more accurate picture of the team’s velocity can be derived from daily stand-ups and sprint retros. Each day is an opportunity to know more about the task at hand and provide a more informed estimate regarding how much time the task requires.

In regards to accountability, we should strive to increase communication to ensure no one is feeling unproductive. Reducing team members to the number of points they can achieve in a sprint can be demoralizing. It’s also not a full representation of the individual’s contributions to the team.

It’s worth mentioning that we have seen story points work well when velocity is being used solely by the team of developers and designers to predict how much work they can complete in an iteration. If anyone outside of the team is tracking these numbers it tends to lead to gamification of the system.

Remaining Transparent

Referencing story points when communicating about a feature adds another dimension to the conversation. This introduces what others may see as a barrier to understanding the development team’s process.

An alternative is to use a metric everyone understands. If an interested party wants to discuss a feature, discuss the work in terms everyone understands, like time. If the interested party would like additional visibility into the process, invite them to stand-ups, retros, and sprint demos.

Prioritizing Features

Discussing the effort required to complete a particular story and assigning story points does have the benefit of highlighting which tickets are believed to be “low effort”. Combining this information with the knowledge of which work is most valuable helps the team identify the work that will provide the most “bang for their buck”.

Alternatively, assigning story points is not a requirement to effectively prioritize features. Try prioritizing stories without story points. This may lead to shorter meetings while continuing to surface the work that delivers the most value to users.

Evaluating the Process

All process has a cost. Are you getting enough benefit for what you’re paying? If you’re getting your whole team together into a room for 30 minutes to an hour each week to put arbitrary numbers on tickets that almost never match the actual time it takes to complete those tasks, maybe consider killing that meeting. Too many times we have seen companies take on the process of story pointing without gaining anything except lost time and mismatched expectations.

In our opinion, story pointing also pushes against recognizing work that no longer adds value. Once a story has been assigned points, the sunk cost fallacy makes it difficult for a team to ask “could we avoid building this”? The story is also rarely revisited, regardless of how the system has changed.

If you find yourself in the situation where story pointing isn’t working for your team, that’s okay. Have the courage to try something else. The goal is to ship working software, not to collect the most points.