Test driven planning uses the same approach as test driven development to craft and know when your project plan is complete.
Test driven development
Any coder, no matter what the software, should always do test driven development. Why? Because it makes you think about the program and all the things that it needs to do. It helps you:
- Understand the full scope of the program
- Draw out the questions that need to be answered
- Highlight areas of complexity
- Understand the programming patterns to use
Only when you have a complete picture should you begin to code. The tests, in effect, become the specification for the program. Once the program passes the tests, you are done.
Test driven planning is the same.
How it works
You draw up a list of 'tests' (a checklist) your plan must pass before it is complete. This works equally well for a product backlog. Typical tests you might include:
- Is the full scope of the project included?1
- Are all the risks and their resolving actions included?2
- Have all the people and resources been identified?3
- Is every task covered by a real person?4
- Is there sufficient contingency for unforeseen events?5
- Has the critical path been identified?6
- Are people on the critical path covered in case of illness or loss?7
- Is there time for meetings and non-project activity?8
- Are people's holidays included?9
- Have several people and your team checked the plan?10
- Does it meet the project's constraints?11
- Has project management time been included?12
Hopefully, you get the idea. Do not release your plan into the wide world until it has passed all the tests. You wouldn't put untested software into production. A plan is the same.
- Work back from a finished product to identify all the things that need to be done. This includes not only the use cases/stories but also all the technical activities, user acceptance, documentation and so on. ↩︎
- Risks will bite you if you do nothing about them. ↩︎
- Not generic resources but real people. ↩︎
- Find out now if you have a resourcing problem. ↩︎
- Or suitably hidden, so some management genius doesn't take it out! ↩︎
- How fast you can really do it. ↩︎
- Very important if one name appears frequently. ↩︎
- The best you will get is 80% full project availability. ↩︎
- Don't go live in August or Christmas, nobody is a round. Allow for slow downs over these periods. ↩︎
- It is not your own private work of fiction. They need to buy into it. Better is to have everyone involved in drawing it up. ↩︎
- If it misses a must hit deadline or overspends, you need to go round again and work out options. ↩︎
- For big projects, there can be project office staff. ↩︎