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:
- 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:
- 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:
- Demo session: PO “demos” the readiness checklist discussed in the 1.PO planning session
- Retrospective: 1.PO iteration retrospective that will allow the PO or Product Team to improve how they “get to ready”
Monday, Week 3:
- 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.