Improve Sprint Throughput with “Definition of Ready”

Software development teams are very focused on customer satisfaction (and rightly so), and there’s no doubt that high team throughput is one of the most important factors in customer satisfaction. According to Wikipedia, throughput is best described as “the rate at which a system generates its products / services per unit of time.”

While there are many factors that affect throughput, I would like to focus on product ownership. In this blog, I’ll look at some issues within product ownership that may have a massive impact on a team’s throughput. I’ll also look at some probable solutions and their relation to the “Definition of Ready” approach, which I’ll explain in a moment.

Below are some common issues related to product ownership that I have personally witnessed while working with various Agile teams:

In a distributed Agile project, the Product Owner’s focus is often fragmented among many projects. As a result, he/she may not have much time for backlog grooming or clearing the team’s queries.

The development team works on half-baked stories because they only discuss stories with the Product Owner during the planning meeting. This may be too late, considering that some stories may require further elaboration or clarifications.

Some teams try to resolve these additional queries by following up during the sprint, but this approach further complicates the issue since the team may not receive answers in time. As a result, story completion gets delayed and the cycle time gets bloated. The Product Owner may also become annoyed by the team bugging him/her all the time with so many questions.

What do you do in these situations? The development team’s management can try initiating discussions with the customer’s management about assigning a dedicated Product Owner to the project, but in my experience, this rarely happens because of Human Resource constraints on the customer’s side. Some teams simply sulk and do nothing about the situation, but of course this only leads to suffering for both the team and the customer. So what other alternatives are available?

Regarding Product Owner bandwidth, why not help the customer help you? One solution is to have the Scrum Master coach the Product Owner on backlog grooming. This approach works pretty well for a small Scrum team, but for bigger teams, the Product Owner may require dedicated help.

Regarding the second problem of half-baked stories, I suggest applying the “Definition of Ready” approach. Simply put, any user story coming from inside the sprint backlog must be READY, and any user story moving out of the sprint must be DONE.

In order to come up with “ready to play” stories, development teams conduct regular backlog grooming sessions with the Product Owner. In a backlog grooming session, the Product Owner explains user stories one by one. The team asks clarification questions and thrashes out all grey areas during the discussion. When a user story becomes clear, and the team no longer has any unanswered questions or blockers, the story is considered READY.

The team then estimates the user story in story points. This process continues through the entire duration of the session for other stories, as well. For some stories, the Product Owner will take note of unanswered questions and then park those stories for further analysis.

Apart from removing blockers, the goal of the “Definition of Ready” approach is to also create a common understanding between the team and the Product Owner on READY user stories. In the teams I worked with, the frequency of backlog grooming exercises was once per week for 2-week sprints. However, it’s up to each team to come up with the frequency that works for best for them.

As you can see, the “Definition of Ready” can range from a simple statement of readiness (left image) to a more detailed report (right image).

For better planning and visibility, the Product Owner and Scrum Master can also share a Kanban board that contains the probable backlog of the next three sprints. Below is an example of a READY Kanban board.

As you can see in the above image, the user stories in the “Iteration+1” column are not implicit candidates for the next sprint planning. Only stories in the “Ready to Play” column are potential candidates for sprint planning. In general, the user stories become clearer as they move from left to right on the Kanban board. For instance, when a story is placed in the “Iteration+3” column, it may have high-level details. As it moves farther towards the “Iteration+2” or “Iteration+1” columns, more details get added and the story becomes clearer.

Working towards this story readiness helps the Product Owner become better organized. At the same time, it helps the development team avoid waiting endlessly for blockers to get resolved during the sprint. By removing blockers from the pipeline early on, you can increase sprint throughput and improve a project’s outcome.

Shrikant Vashishtha is the Director of Engineering for GlobalLogic’s CTO department. He has over 15 years of experience in the IT industry and is currently based in Noida, India.