The Definition of READY

August 21, 2009 by Jason in Scrum Tips | 3 Comments

Serge Beaumont posted a great article on the The Definition of READY at Xebia Blog.  While the concept of being ‘ready’ for iteration planning is already in Scrum, I have found that it’s not something that gets a great deal of attention.  Product Owners are left to “get stories ready” without having a clear definition about what that means to the team.

I think the power of self-organizing teams have trained people to leave out the “how” until the team decides that in the planning session but as Serge points out “how” is a by-product of iteration planning and I would tend to agree.  Teams need to have some understanding or thoughts of implementation before they can commit to a batch of stories and a Definition of Ready is a great way to get there.

The problem I see with the Definition of Ready is that it can be quite complex depending on the type of story.  You may have stories that require UI changes, look and feel or legal changes that would make your Definition of Ready bigger than say stories that are geared towards updating an API or adding simple functionality.

Should you define the definition of ready for each story?  Should you have a base definition of ready and add/remove items as necessary?

Personally, I would move to having a Product Owner work in iteration sizes that are half the length of the team’s iteration to prepare stories with the definition of ready.

Monday, Week 1:

  1. Iteration 1.T (the teams iteration) starts

In the Teams iteration planning session the team commits to their work, does their detailed estimates and task breakout.

During this week the PO or Product Team is grooming the existing backlog, re-prioritizing stories based on output from the last demonstration and working with the customer, again, to groom the backlog.

Monday, Week 2:

  1. Iteration 1.PO starts: this is the PO or Product Team’s iteration to “get to ready” for the next set of prioritized user stories.  The PO meets with the team to define what ready for these stories mean.

Friday, Week 2:

  1. Demo session: PO “demos” the readiness checklist discussed in the 1.PO planning session
  2. Retrospective:  1.PO iteration retrospective that will allow the PO or Product Team to improve how they “get to ready”

Monday, Week 3:

  1. Iteration 2.T (the team’s next iteration) starts: The team defines and commits to the stories that were given the “ok on readiness” from the previous Friday.

The benefits of this approach is that all the “readiness” activities can (and should!) be timeboxed so there is an expectation that the team will need to participate in another short session.

It also helps get the PO and Product Team into a rhythm while also leveraging the power of retrospectives so they can improve on how they gather stories and get them ready.

I threw this post together rather quickly but it’s something I’ve had noodling in my brain for a while, would be very interested to hear others thoughts and experiences about how you get to ready.

Social tagging: >
  • Wouter Dewanckel

    That is exactly what I am trying to push into our scrum processes. Though it is not easy to free the PO on weekly bases. Which makes no sense of course, since we pay for it later on, during the sprint planning meetings, that could be much shorter…

  • http://www.agilecoach.ca Jason Little

    Thanks for the comment Wouter. Something you may want to try is to reflect back to the team the pain not having ‘ready’ stories is creating. If you can help the PO understand the impact not having ready stories is having, he/she may be more willing to take some time to be available.

    I’ve found it helpful to timebox a specific day and time each sprint dedicated to grooming the backlog with the goal being to prepare stories for the next sprint. This sets an expectation with the team and PO. Scrum recommends spending 2 – 4 hours per sprint getting stories ready for the next sprint, of course assuming a 2 week sprint length.

  • http://www.onesandthrees.com Andy Roberts

    One way to look at this is that the PO is failing in his responsibilities, and that as a result, the team is accepting responsibilty for the stories that aren’t ready, and trying to complete planning as if nothing was wrong. So one option is for the team to start refusing to deal with the worst ‘not ready’ stories (e.g. “We really don’t know what this means”), prompting the PO to address the situation. If this is done in a non-confontational way, perhaps at the same time offering to spend time with the PO grooming stories, or perhaps negotiating a common definition of ‘ready’, then you should be moving in the right direction. Have these issues surfaced in retrospective ? Does the team realise it has the option to address this situation as opposed to accepting it as a given (I’m inferring that’s what’s happening at the moment.) ?

Switch to our mobile site