One crucial element of all planning that is frequently ignored is the fact that the planning process will itself frequently lead to changes. You get new ideas, unexpected implications evolve before your very eyes, new information is discovered, and so on. So before you commit to delivering, validating the plan is vital.
But what do you validate it against? That depends on the specific type of plan you’ve just prepared. In the case of your iteration plans, for example, this would be a reasonable list of things to check it against:
- The iteration/sprint’s goals.
- Are these still achievable, give the work you’ve chosen to do?
- If not, who needs to know and agree?
- Backlog prioritisation.
- Are the stories in the scope of your plan the highest priority items?
- If not, why not? Who needs to agree this?
- Or has planning itself shown that the backlog need reprioritisation?
- If so, have you done that too? And understood the implications?
- Your Definition of Done.
- Given how many items in your DoD won’t be obvious from just listing the stories you plan to deliver, has the impact of doing things properly been fully allowed for?
- Known issues with the iteration.
- What is their impact likely to be? Delay? Risk? Dependencies?
- How will you manage it?
- Your release plan.
- Is this iteration/sprint plan fully compatible with the release plan?
- If not, who will you impact? Who needs to agree to the impact?
- Your Iteration 0.
- Has it prepared you fully for this iteration, now that you’ve finished planning?
- If not, what extra tasks do you need to carry out? Who will do them? Does this delay your plan?
- Is there any duplication that could be shared across multiple stories? E.g.:
- Technical tasks that are repeated for more than one story.
- Testing that could verify more than one feature.
- New dependencies.
- If the plan creates new dependencies, who will manage them and how?
- Is whoever is on the other side of each dependency aware of and happy with it?
- Major development overheads.
- Have you made realistic allowance for refactoring, test maintenance, etc.
- This is especially relevant for inexperienced teams that don’t allow for these factors intuitively yet.
- External events and deadlines, and other unavoidable downtime such as public holidays, personal leave and company events.
Finally, the plan needs to be compared with the team’s historic velocity.
- Are we really able to do all this in the time available?
- Could we (sustainably) do more?
This probably seems like a rather formidable list! But before you dismiss it, ask yourself, if one of these things didn’t match up with your plan, wouldn’t you want to know? And anyway, you’ll soon get used to all these factors, and validating you plan against them will not just become a quick and easy process but in fact you’ll quickly find yourself asking all these questions as the plan is being prepared.