Definition of Ready
In one of our first posts we described our Definition of Done. A set of guidelines that states when a story may be considered done and ready for deployment to production. In this post we will discuss our definition of ready, when a story is considered ready for development.
During our bi-weekly planning sessions we often encountered stories that needed more discussion (grooming) before being fit to add to a sprint. So to keep the planning efficient and devote as much time as possible to sizing and determining what should go in the sprint, we decided to create a Definition of Ready: a set of guidelines similar to the Definition of Done, but with the purpose of defining when a story is ready to add to a sprint.
Definition of Ready
Our Definition of Ready currently consists of the following:
Who gains the most when the story is implemented? In most cases there’s only a single stakeholder and in most cases that’s the end user. But we’ve discovered it’s good to explicitly point this out. It reminds us to view the story from this stakeholder’s perspective, fulfilling the story’s intent better.
What problem are we going to solve? This might be the most important part of the user story as it describes the purpose of its existence. The problem is the part that’s going to be tested. Here’s where all the intent of the story is and therefore requires apt description. The problem often arises from the stakeholder (or a representative) and the product owner uses it as it’s main indicator to determine its priority relative to other stories.
What solution do we think is the best (or least worst) to solve the problem? Before writing the story, the product owner has some discussion with (a) member(s) of the team to determine what solution is best. A conclusion can also be that more research is needed. In that case we create tasks (business-valueless stories) and time box these to facilitate the solution for the actual story. We strive to have all discussion needed to find the solution out of the way for the story to be ready.
Acceptance criteria are small, atomic and testable manifestations of the solution. They represent the implementation from the stakeholder’s perspective, not the developer’s perspective. Again: a story is written for the stakeholder, this forces the developer implementing the story to think like the stakeholder in order to create the required business value. A story requires at least one acceptance criterion.