Definition of Ready

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.

4 Replies to “Definition of Ready”

  1. On my last team, after a few years, our team’s efforts to learn the domain had an interesting side effect. The biz folks seemed to think we could make up the business rules for stories ourselves. This caused a lot of what we called “story churn” as we had a lot of back-and-forth going to the biz experts to get examples of desired/undesired behavior. That was such a frustrating waste of time.

    We decided to push back. We told the PO that if we didn’t have all the business rules, mock-ups, and other pertinent info for a story on Day 2 of the 2-week iteration, that story would be taken out.

    Then we did that. We actually had an iteration where we took out all the stories as we didn’t have enough to start any of them. We just worked on managing our technical debt that iteration.

    It didn’t take long for all the stakeholders to be proactive about going over all the business rules, mock-ups and other requirements before the start of each iteration

    I’m struggling with this on my current team. In some cases we don’t have enough information up front. In other cases, we do have the information in our online story, but the devs neglect to read it. So we may reject a story multiple times. I think the answer to this is more Three Amigos and specification by example.

  2. I have had a lot of success with a very simple refinement process, the whole team is booked 30 minutes every second week to sit with the P.O. and dicuss the upcoming stories. It started as an hour every week, but after the first few, that was too much. The team has been very enthusiastic about the result, as we have decreases planning from 4-8 hours to 1-2 hours for a Sprint now.

    We have been quite successful with a very simple definition of ready. “The entire team agrees that this is ready, and can be worked on at any time.”

    Also, something that has helped a lot has been visualising the refinement flow for our customers (stakeholders), so they can see where in the pipe things are.

    I have tried to avoid specifically “rejecting” stories, as I feel that tends to build an unhealthy attitude between stakeholders and the team, instead we look at things that were not appropriately detailed, and use them as discussion points as to where all parties can improve next time.

    1. Thanks, Jeff. That definition of ready leaves it a little vague as to what is the team’s criteria for ready. As long as it’s working for you, that’s fine. But if sometimes things are less ready than others, the team might want to consider what makes them agree on readiness in a little more detail.

  3. We kind of follow the same process/framework mentioned by Jeff Campbell. Our scrum team’s meets every 2nd week Wednesday to review the ranked backlog with the PO to discuss about the questions/clarifications before we get into planning meetings (named internally in our company as pre-planning meeting). I as a product manager responsible for providing the business rules/cases & provide enough details before we get out the room during pre-planning meeting.

    It really works well as off now for us. We also deeply discuss on WHY part during the pre-planning meeting before we take up story during our planning meeting.

    This really saves time during planning meeting and also team’s get good understanding of user stories.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.