Many time, in the middle of developing a user story, the programmer discovers a question about how it’s intended to work. Or the tester, when looking at the functionality that’s been developed, questions if it’s really supposed to work that way. I once worked with a team that too-often found that, when the programmer picked up the card, there were questions that hadn’t been thought out. The team created a new column on the sprint board, “Needs Analysis,” to the left of “Ready for Development,” for these cards that had been planned without being well understood.

It was that problem that the Three Amigos meeting was invented to address. Rather than wait until a story was in the sprint to fully understand it, stories that were on-deck for the next sprint would be discussed by representatives of the business, the programmers, and the testers to make sure that all the questions were answered before considering the story ready for development. Sure, the occasional question still came up during development, but the epidemic had been stemmed.

Since that time, I’ve found better ways to determine if a story is ready for development. I look for the list of essential examples, or acceptance scenarios, that the completed story will satisfy. These provide a crispness to the understanding of the story that’s hard to achieve any other way.

There are fringe benefits to going to this level of detail. Planning discussions of the story don’t spend a lot of time understanding what the story means. These discussions don’t go round-and-round finding the boundaries of the story. If the scenario isn’t listed, it’s part of another story (or it’s been overlooked). In fact, dividing the scenarios into groups is a simple way to split a story into smaller ones.

Another benefit is that the scenarios can be automated as acceptance tests prior to the development of the functionality. Having a clear picture of the outcome before starting helps keep the development on track, minimizing premature speculation of future needs and maximizing attention to current edge cases that might otherwise be overlooked.

In a development process that uses sprints or timeboxes, you’ve got the whole sprint to get the next sprint’s worth of stories refined prior to planning. If you’re practicing a single-piece pull process, you’ve got the length of time a story spends in the development input queue to do so. Either way, refining the backlog is a necessary overhead activity that should be done a little at a time, all the time.

The goal is to have the work done just-in-time for planning and development. It should be complete enough to avoid stoppages to build more understanding, but not so far in advance that the details get stale. We want our scenarios to take advantage of the most knowledge we can bring to bear. If done too early, we may have to revisit the scenarios to see if we need to alter them according to what we’ve learned since we created them.

More often than creating too many acceptance scenarios too early, I find teams spending this effort too late. It seems a lot of work to go to such detail when we know we’ve got a mountain of work to accomplish.

Developing software correctly is a detail-oriented business. We’re going to have to get to that detail sooner or later. Leaving it until the programmer has a question causes interruptions in development, delays, lost effort, and, sometimes, unwarranted assumptions that give us results we don’t want. Don’t look at the mountain of work. Look at the little bit of work we’ve decided to tackle next. Do a great job on that, and things will go more smoothly.