Scouting Your User Stories

Most Agile teams plan work for an iteration by assigning points to user stories and selecting as many stories off the top of the priority queue as will fit within that team’s projected velocity for the iteration. In larger projects, the stories are often written and prioritized by a project manager or some other person who has a vested interest in the success of the iteration but is unlikely to be implementing the stories themselves.

When story point estimation goes well, the iteration planning meeting is a valuable communication tool that allows the development team and outside stakeholders to align expectations for the iteration. When stories are poorly estimated, however, things can go very badly. Developers are hurt when they get little recognition for hard work, and project managers suffer when what seemed to be a reasonable plan fails.

Causes of Poor Estimation

So what causes poor points estimation? Any number of things, but the problems I see most often are:

• Developers arrive at the planning meeting lacking familiarity with the user stories on the queue.
• The stories are unclear, missing requirements, or have dependencies that are not yet ready.
• The stories involve work that is substantially different than what the team has been doing, work for which the team doesn’t have an “oh yeah, we basically know how to do that” reaction.

How do you address these problems? Talking through the stories during the planning meeting is no good. It’s an extremely inefficient use of the team’s time, and people leave frustrated. Asking the team to review the stories prior to the meeting seems like a reasonable compromise, but it doesn’t work either. Since reviewing the stories is everyone’s responsibility, it’s nobody’s top priority; and when things get busy, no one has the time. It’s also inefficient to have the entire team independently review the same user stories.

Scouting Ahead

What we’re trying on my current team is to have a “story scout.” This person’s role is to look ahead to the next iteration’s stories and:

• Ensure that each story’s goal and exit criteria are clear.
• Communicate with the right people to gather information and align schedules if a story has dependencies outside the team.
• Do enough upfront investigation so that a basic approach to solving the problem is identified. This is not a detailed design, but it should be possible for the scout to suggest some workable implementation path so they can explain that “you basically need to do x, y and z” in order to solve the problem.

Your scout should be a person who:

• Has the team’s trust in their technical ability. Otherwise this is a waste of everyone’s time.
• Gives a shit about estimating well, and will be accountable if stories are grossly misestimated.
• Will be directly responsible for implementing some of the stories.
• Has the political will to make time for their scouting duties.

The idea is to make it one developer’s top priority to take a hard look at the next iteration’s stories before the planning meeting. We expect this will mean that our stories are in good shape for estimation. It should also reduce the chances that we run into nasty surprises after the iteration plan has already been committed. This should also help the team avoid padding story estimates to account for unclear requirements or cases where we don’t really know what the implementation will entail.

We hope that good scouting will improve our estimates and smooth out our progress during iterations. Does your team use a similar approach? Or do you have other ways of handling story estimation problems?