Focus on Ready

With a few years of experience with Scrum, by far the most obvious (easy to identify) and most consequent “adaptation” roams around the concept “ready”, especially teams that are transitioning or adopting Scrum and have no/low experience.

I still remember the first time that I was introduced to the concept “done” (online guide, certification) and the “OMG” feeling thinking “I really get/need this”, but the same feeling for “ready” only came around a bit later. At the time (the beginning of the journey) you could already find some great posts and articles online from well know agile product management consultants/coaches about it, but I guess I didn’t have the need at the time… didn’t quite get it yet… Basically I still was a newbie, and as usual nothing like practice for the ideas and concepts to come around and kick in naturally.

Since I truly believe our/others mistakes (aka pitfalls) is the most humble and wise way of learning, there are more & more organizations and new teams adopting Scrum, it is never too much emphasizing the importance of this concept “ready”. So here it goes once again!

Why is “Ready” so important ?

In order to pull items into a sprint and quickly turn them into product increments, the high-priority product backlog items must be “ready”!

fb FB_comparison

Scrum two stable “states” with the following principles that is linked to “ready”:

  • Never pull anything into a sprint that is not ready
  • Never let anything out of the sprint that is not done.

If the items that are likely to be worked on in the next sprint aren’t ready, then the team cannot create a product increment (I always remember it as “garbage in, garbage out”).

What does “Ready” mean ?

A “ready” item should be clear + testable + feasible:

  • clear – if all scrum team members have a shared understanding of what it means (collaboratively writing user stories, and adding acceptance criteria facilitates clarity)
  • testable – if there is an effective way to determine if the functionality works as expected (acceptance criteria ensure that each story can be tested, as a rule of thumb, three to five acceptance criteria per user story)
  • feasible – if it can be completed in one sprint, according to the definition of done (implies the item must be small enough, and must not be too complex)

Ready items are the output of the product backlog grooming (aka refinement), i.e., your grooming activities should result in “ready” items.

What does a “Ready” item looks like ?

A “ready” item is a detailed user story with a narrative and acceptance criteria. Typically, the user story should answer the following three questions:

  • Who – Who is the end user that will benefit or asked for this feature?
  • What – What is the outcome vision? What is the end result of the user story?
  • Why – What are the stakeholders or the business trying to achieve? What is their goal or outcome? What is the business context?

It should also be clear if there are any specific operational qualities, conditions or constraints, such as performance, and what user interface design should roughly look like.

In practice, it may not be always possible for an item to be 100 % defined (all acceptance criteria), however, it is important that the item is “ready enough” that the team can be confident in committing to deliver it in a sprint.

Definition of “Ready”

The Definition of “Ready” (DoR) defines the ready state, which is a collection of all the conditions necessary for an item to be pulled into a sprint. These conditions should be defined by discussion among the team, the product owner, and the scrum master. The DoR is important so that everyone on the team is aware of what it means for an item to be “ready”.

Example of our DoR:

Story = New Feature/Improvement

  • Issue written according to template “New Feature and Improvement Descriptions”
    • A clearly defined “user” (check the “Users and Personas” wiki page)
    • Issue must meet the INVEST criteria
    • Acceptance tests added for more complex issues
  • External information that can provide better context linked/attached
    • Linked to epic (bigger scope/next steps of epic)
    • Linked to dependencies (related, blocking, etc)
    • Screen mockups
    • User journeys
    • Architectural drawings
    • Business rules
  • Issue has been prioritized in the product backlog
  • Issue has been estimated by the team
  • Issue status updated in JIRA (state = “Ready for Development”)

Story = Bug

  • Issue written according to template “Bug Description”
  • Issue has been prioritized in the product backlog
  • Issue has been estimated by the team
  • Issue status updated in JIRA (state = “Ready for Development”)


Benefits of focusing on “ready”, having a DoR… basically implementing product backlog that are “ready”:

  • Helps the product owner in organising the product backlog Avoids wastage of time/effort, rework or back-and-forth discussions (both, when starting work and * stopping/delay after a few days of work)
  • Keeps the team members more engaged and accountable to each other
  • Helps the team identify when a team member becomes overwhelmed
  • Provides the team with an explicit agreement allowing it to “push back” on accepting ill-defined items
  • Reduces pressure on the team to commit to estimates before stories are “ready”
  • Reduces feature churn in development

The complete team (PO, SM, Dev/Scrum) should be really committed in creating high-priority product * backlog items that are clear, testable and feasible!