Lately I’ve been on a bit of a high horse about the discipline of having backlog items “ready” before a team takes them into an Iteration Planning session. Traditionally, we define Iteration (or Sprint) Planning to have two parts. 1) Where the stories are reviewed and have final grooming done. 2) Where stories are decomposed into tasks and an Iteration Backlog is created and Iteration Commitment is achieved.
And as I described in my post “Release Planning Won’t Happen Overnight” the discipline of creating Release Plans and Grooming the Product Backlog is essential to achieving success with the Agile Framework. A key aspect of that is authentic and accurate commitments during Iteration Planning, so I ask…
Why would you ever try to plan tasks and commit to delivering a story if it isn’t ready to be worked on?
I use a filter of 4 questions + 1 optional question to determine if a story is ready to be planned and committed for an iteration.
- Do we understand the story & the acceptance criteria?
- Do we have the story sized properly?
- Do we feel confident we can start & finish the story within a single iteration?
- Do we know enough about the story to define all the tasks necessary to meet our Definition of Done & the Acceptance Criteria defined?
If you can answer “yes” to all of those questions, then you can consider a story “ready” and I think it is a candidate to take into a Iteration Task Planning session.
I mentioned there is one additional question I sometimes throw in the mix. I do this when a team has external dependencies that must be delivered in order for the team to complete the story. So, the question is…
- Do we have all necessary inputs from external stakeholders required for this story to be complete?
Then, only if the team can answer yes to all 5 questions will the story be considered “ready.”
Having the discipline to track the status of an item within the backlog is a great way to track the depth of the Product Backlog, and taking the time to designate stories as ready should increase the accuracy of task planning work at the beginning of the iteration. I find that teams that rigourously track “ready” stories see the following benefits:
- Faster task planning, because there are fewer option questions.
Leaves more time for building the product.
- More accurate task planning.
They’ve had the disciple to collaborate and turn over all the ‘big rocks’ in advance.
- Higher Complete vs. Commit (CvC) ratios.
More accurate tasks yield more accurate commitments yield higher reliability for delivery.
- Better quality.
The forced collaboration in advance helps ensure they are building the right thing.
Hoping your team would see similar benefits!