Avoid Surprises at Sprint Planning, create a Definition of Ready

There has been a lot of talk over the years about having a definition of “Done” or “being Done”, but I think it is just important to have a definition of Ready.

Have you ever been in Sprint Planning and been surprised to find out the requirements aren’t clear or the team has no idea how to implement it?
 
Definition of ready as an adjective: fully prepared for immediate action or use.
The original Scrum writings stated that Sprint Planning should be done in two parts:
  1. Review the scope and understand the stories
  2. Task the stories

More and more, I see teams conduct part 1 earlier, during the previous Sprint in backlog grooming sessions. The goal is to work ahead just enough to limit the number of surprises during Sprint Planning and consequently, the Sprint. To know what is just good enough, you should define your Definition of Ready. i.e. What does it mean for your team to be ready to start a Story in a Sprint?

I recommend teams spend up to 10% of their time preparing for future Sprints. This may involve activities such as the following:
  • Reviewing Epic or MMF (Minimally Marketable Feature) stories and breaking them down into Sprint Sized Incremental Stories
  • Having conversations with the Product Owner (PO), Stakeholders and/or customers to understand their needs and working with the PO to document the Acceptance Criteria
  • Discussing new stories and providing a rough sizing estimate so they can be prioritized
  • Thinking about what will be needed to implement the story: New HW or SW? New Knowledge? New Architecture? Paying off accumulated Technical Debt?
  • Working on just enough design to keep things flowing. It is common for UX Designers to work about a half a Sprint ahead of the rest of the team.
So if your Sprints have a lot of surprises, you might consider working with your team to form a Definition of Ready and allocating time to work a little bit ahead. Your Sprints should flow like a track relay where the next runner is already running as the other one starts. Don’t start your Sprint’s flat-footed.
 
For further information, see our Evolution of a User Story post to learn more about how to get your stories ready.