Communicating Plans in Agile Development

Name: Communicating Plans in Agile Development
Type: Rules
Status: final
Version: 2007-08-23
Gist: How to communicate a release or iteration plan to team members and to management
Source: Mike Cohn (Agile Estimation and Planning, 2006), my own tested ideas.

R1) You should communicate often, a plan is there to change. This keeps you updating the plan.
R2) You should communicate honestly, you want trust among your team and your bosses.
Note: Agile Planning is about providing real options. Don't get trapped in your own inappropriately communicated release dates.
R3) Make sure communication is two way. It's much easier to get a commitment from everybody if you involve people.
R4) If you're using Gantt charts, try to get away with a plan of milestones only. There may be lots of small milestones between the bigger ones. You may render the plan more readable if you include activity bars between milestones. They should not be connected to the milestones.
Note: remember, the bars are for readability only.
R5) If you're using Gantt charts, don't show a work breakdown structure; do a feature breakdown structure instead. Don't show individual's tasks.
R6) If you're using Gantt charts, show each feature with the lenght of the iteration.
Note: Some tasks relating to the feature will start at the beginning of the iteratioen. The feature will be finished at the end of the iteration, not earlier.
R7) Talk about a due date with a specific degree of confidence or by using a range or both. You may want to use the 50% and 90% confident numbers.
Note: This correctly reflects the degree of uncertainty that is inherent in future.
R8) For communicating or predicting feature burndown, use three numbers: velocity of the most recent iteration, average velocity of the last 8 iterations (or as many as you have, if less), average velocity of the worst 3 iterations.
R9) In reporting or planning test results, use either the number of passed tests (if all tests passed) or the number of failed tests (if at least one has failed).
Note: It does not make sense to report or plan based on failed tests vs.passed tests. In test-driven or even behavior-driven development, a feature is considered finished if and only if all it's tests pass. There's no 'finished to a degree'. You're aiming at zero defects.