ScrumCar

In a meeting with other Scrum Masters today, someone asked how they could handle the following situation: how can they coach a lead developer who assigns stories to each person on the team during sprint planning to make sure everyone has enough work? I didn’t have enough expletives to form an adequate response.

Sadly this situation is all too common. Story points are probably the most misunderstood concept in all of Scrum, as well as one of the most abused. Teams frequently equivocate them with time (typically 1 sp = 1 day). Department heads are always trying to “normalize” them so a point has the same value for every team. Managers want to use them to evaluate each team member’s contribution, and to make sure everyone is “doing their fair share” of the work.

Anti-patterns like these make story points the enemy in so many Agile organizations. The job of a Scrum Master is to prevent anti-patterns that result in ineffective estimation, turning it into a useless exercise. But how do we do that?

Set Guidelines

The most important thing you have to do as a Scrum Master is to define what story points are, and who they are for. Because that definition is often not what managers want to hear, you have to keep reinforcing it. Story points are for the team only. Whether its a regular number sequence, Fibonacci, or t-shirt sizing, this method of estimation must be understood and used exclusively by the team for the purpose of estimating stories in their backlog. They should never be used for external reporting, shared in sprint reviews, or used to “grade” developers. By their nature, story points will evolve along with the team, and at any given time based on experience levels, a 3 may mean something different to each member of the team.

It’s not going to be easy to establish guardrails around story points, particularly in a young Agile organization. Managers love numbers and spreadsheets, and they’re always looking for information to analyze. You have to persistently enforce the rules about estimation to protect your team.

Define Story Points with the Team

You need to make sure your team doesn’t misuse story points. Otherwise they become a useless tool that will have ripple effects throughout your Scrum processes. The number one mistake teams make is equating story points to time, usually settling on 1 story point equals 1 day. The problem is that using the numbers in this way is a poor method of time-keeping. If you want a time-based approach, why not just keep a timesheet?

Story points are intentionally nebulous. They should represent effort, not a schedule. These measurements should naturally differ based on team member experience. This will foster discussions that create opportunities for learning, pair programming, and mobbing. As a team matures these differences will become smaller and will draw comparisons to past stories. Advanced teams will often say things like, “This story feels like a 3” and you’ll get to consensus faster. Estimation will become less of an effort, and your team will continue to get more accurate.

Other Tips

In the process of getting your story points sorted, don’t forget to frequently compare your estimates with your throughput. Too much sprint carryover could mean you committed to too much work, but it could also mean that you’re not very good as estimating yet. It’s critical to inspect the process frequently when you’re getting started. Make sure the team is reviewing stories that carried and identifying what they missed. Was there a lack of discovery? Did the story need to be broken down further? Is there a bottleneck at some point in the process such as QA taking more time or pull requests not being acknowledged fast enough?

In situations where you can’t seem to get consistent results with numbers, try switching to t-shirt sizing. Have the teams estimate a story by giving it a size of small, medium, large, or extra large. If your organization insists on using story points, treat the numbers as t-shirt sizes, such as 1=small, 2=medium, and so on.

After you have a baseline for how your team uses story points, it’s helpful to define a maximum value. That is, agree as a team on what single story value is too much to take into a sprint. For instance, my teams have agreed that 1, 2, and 3 are the only values they will accept. A 5 or higher must be broken down further. If two developers are going to pair on a particular story we will occasionally allow a 5, but as a general rule we recognize that, for our process and skill level, 3 is the maximum an individual developer can take.

It’s a Team Decision

Ultimately there are a lot of decisions to be made when you form your guidelines around story point estimation, but it has to be a team decision, with a healthy amount of coaching from the Scrum Master. Decide quickly what your limits are, make sure they adhere to principles of iterative development, and stick to them. Unlike other areas of Scrum where outside influence is merely an annoyance, misuse of story points can cause real fractures in team cohesion, morale, and trust. This is one area where a Scrum Master absolutely has to have the team’s back.