I recently received an email asking about release planning. The sender wanted help understanding how to move ideas through the flow to create a mature backlog. The note went on to ask how to properly “estimate, prioritize and reach an aggressive but realistic delivery date”.
My immediate thought was, this is agile: total project story points divided by team velocity yields the duration of the project. And delivery date then only depends on when you start and how well you manage risks and dependencies. If you want an “aggressive” or what I’ve come to understand as “overcommitted” plan you should just crack out your Gantt charts and stop pretending that you’re agile.
Before I dashed off a sharp email, I chatted with an associate and came to a different understanding of “aggressive planning”. He made the point that teams may not be aware of unused capacity. And establishing an accurate team velocity is a “trust but verify” process. Trust the current velocity, but periodically verify its accuracy. After a team establishes a sustainable and consistent delivery velocity, you should run an experiment. Increase the number of story points planned for a sprint by some number. If the team successfully delivers the sprint, then that total number of points is used for planning successive sprints. If the team sustains that pace, then reset the team’s velocity to the new number. Run the experiment again.
This cycle of experiments continues until the team can’t keep up. At that point you have verified the team’s velocity as the last consistently maintained pace. This final velocity is likely a bigger number (more aggressive) than the starting velocity number and so now a project’s duration will be shorter than calculated with the untested velocity. But the new velocity is verified; consider the date realistic.