Sunday 14:15 – 15:00
The first question on a project is always â€œwhen will you be done?â€ Agile planning takes place on three levels, using relative story size and previous performance (velocity) to plan iterations and releases.
Agile teams plan at the release, iteration and daily level.
Release planning describes “Here’s where I want to be” – so that we can figure out the best way to get there. Releases usually comprise multiple iterations, because stories are “done” at the end of each iteration – not necessarily cohesive. Estimates at this level are ball park numbers – it should take no longer than 3 minutes to get to the estimate for each story. During release planning, the team explore the solution space and negotiate how they can satisfy the customer’s needs.
At the iteration level, tasks are estimated in “hours I thought a lot about”. There is no negotiation on schedule or budget at this level – long iterations with varied lengths don’t work. At the end of the iteration, get feedback of what’s done and left to do.
At the daily level, the daily stand up meeting is used to plan the next day’s work and synchronize the team. This should not become a status meeting.
Humans generally are bad at estimating the duration of a task, but relative sizes are more straightforward. Some teams use t-shirt sizes to estimate stories, but it is difficult to agree on the relativity – is a large story twice the size of a small one, or three times? Story points, which are the most commonly used now, make this straightforward.
A common mistake is to consider the skill of an estimator important – it isn’t. Regardless of time, people can agree on the size of a piece of work.
To estimate velocity, use a range. When considering the long term average, look back 4-5 months and no longer, as the team’s situation will have changed too much if you go back any further. Use the velocity to look at the release plan and estimate where we’ll finish at the slowest velocity and expected velocity. These estimates can be used to reprioritize the stories.
Burndown charts show progress. Teams generally work best when they have slightly aggressive, but not unrealistic, schedules – which is why the end of the burndown chart is usually steeper. Burndown charts raise questions – they don’t answer them, but they identify areas for further discussion and commentary.
The powerpoint contains diagrams, further explanations, and photos of example taskboards.
Key points to put into practice:
- Use velocity to estimate the relative likelihood of stories being completed in a release, and use this to drive reprioritization.
- Use burndown charts to identify areas for discussion, where further explanation is needed.
- Track velocity only about 4-5 months back â€“ changes in the teamâ€™s situation can cause velocity to change over time.