Is Your Backlog Ready?
Do any of these problems sound familiar?
We have lots of unanswered questions in our Sprint planning meeting
It’s hard to estimate the size of the features or user stories for the Sprint
We discover dependencies half way through the Sprint and can’t get things done
We have tons of rework and changes requested - after we finish a feature
If so, the root cause might be that your features (or user stories) aren’t defined well enough for work to get started - they’re not ready for the team. A good solution is to make the readiness (analysis) process explicitly to your team’s workflow. Your new workflow steps may look something like this:
Product Backlog —> Ready —> Sprint Backlog —> In Progress —> Done
The key is visualizing the readiness step, and to keep that step populated with ‘ready’ items. My rule of thumb is to keep two Sprints of items ready at all times. If you’re using an electronic tool, add the Ready column to your work flow, or if this is not possible, use some other visual indicator such as a label or color to indicate ‘ready’ items. Kanban calls this the replenishment process, and it would have an associated policy for defining how work gets to be Ready. Some teams call that the Definition of Ready, and it may include these types of standards:
The item is the right size (small enough to fit in a Sprint)
It has enough detail that we are confident we can build it the right way
We have resolved any external dependencies, or have a clear plan for how to resolve dependencies in the necessary time frame
This simple step can often cure a lot of downstream headaches.