When I first heard Jeff Sutherland talk about ready-ready I thought he meant that the product owner should know what he/she wants when turning up at the sprint planning meeting. That sounded obvious but anyway a good thing to make sure. At the JFocus conference in Stockholm early 2010 he talked about ready-ready-checklist and now it hit me that he meant something more than just that the product owner knows what he/she wants.
Here is my new understanding of the concept ready-ready. It’s simply that you should avoid things that might end up with a failure. So, what are the reasons for failure for you? Make a checklist of those possible failures and validate each story against it before you pull them into the sprint. The checklist becomes a recipe that gives your team the best possible start for a successful sprint. The checklist will of course vary from team to team but here are some examples.
Only pull stories into the sprint that fulfils the following:
- The product owner should know what he/she wants
… to minimize the risk he/she changes his/her mind - All major stakeholders must agree that this is what they want
… to minimize they get annoyed and want you to change it back - The team should fully understand what the product owner wants
… to minimize the risk he/she gets disappointed - The team should know how to develop it and have the persons needed
… to minimize the risk there will not be persons there to do the job - The team should have all needed knowledge or at least access to needed knowledge
… so we are not delayed waiting for answers - The team should have the environment that is needed
… so we can work in maximum speed - The story should be small enough to fit in a sprint
… so we can complete it during the sprint
If any bullets above are not checked then there is a possibility for some sort of failure and then it might be better to wait with the story to the next sprint and develop something else in this sprint instead.
Before the next sprint planning meeting we have time to fix what was missing.
Then there are two things that I think will help but is not mandatory:
- The team should understand the value of the story
- The team should understand how the new feature is about to be used
What if something needs to be done but some of the criteria above is not fulfilled? Maybe the best thing to do then is to timebox. Work with the story for a fixed amount of time and then either you are done or at least you have more knowledge to take a decision what to do.
Who’s going to do all this, you may ask. Well, who makes the goals in a football game? Usually it’s the centre forward but it could be anyone in the team.
So, only bring stories into the sprint that are truly ready-ready. Avoid failures and go for success.
By the way, leave the stories done-done after the sprint 🙂
