Earlier this week at a combined Agile Ottawa/Ottawa Scrum User Group joint event, Joe Little facilitated an entertaining discussion about the basics of Agile release planning. This gathering was instigated by a question at an Agile Ottawa meeting a few months back about whether any sort of release planning happens in an Agile context. Given that much of the Scrum canon just does some vague hand-waving around this topic, it’s understandable that there is some confusion out there about what kinds of release planning a team might wish to undertake before diving into the nitty-gritty of getting things done.
Some teams breeze right past release planning — I’m constantly amazed that organizations in the habit of taking months or years to collect and sign-off on project requirements balk at spending a few days workshopping a release plan before jumping into delivery mode because “It takes too much time! We need to get started!”. Others spend weeks doing big upfront architecture and detailed design in the guise of “Iteration Zero” before writing a single line of code. Neither approach makes sense. It’s well worth spending a brief period of time to take the team on a few trips around the elephant to develop a shared understanding of the problem to be solved, but the amount of time spent should be limited to just enough to develop an understanding of the big picture, get the conversations flowing, and to resolve the relatively few decisions that really must be made up front. For a release plan for 6 months of work, it might be reasonable to spend 3-5 days having a release planning workshop with the whole team: scale up or down relative to your intended release cadence.
So what do you need to do to get started? Here are the basics of Agile release planning:
- Introductions: Get everyone in the room together – product owner, team, key stakeholders – and do some introductions/activities so that people get to know who they’ll be working with. Even in a relatively stable environment, there are likely to be new faces on the team, which means you have a new team.
- Why are we here?: Share the vision statement for the work, and the value of finding a solution (put into dollar terms if you can, or some other quantifiable measure of importance). What are we trying to achieve here? How much is it worth to us to solve this problem? This is a great opportunity for an Important Project Sponsor to make an appearance and explain the value of this project to the organization.
- Create the product backlog: identify the roles/users within the system, and feed that knowledge into a user story workshop to create a release map of user stories based on roles and activities.
- Assign business value to the backlog: Discuss what ‘business value’ means in this context. Then use Planning Poker or another relative estimation technique to assign Business Value Points (BVP) to stories.
- Estimate the backlog: Have any upfront infrastructural/architectural discussions that may be necessary to get a big picture of where things are going and to identify technical decisions that need to be made up front (which are usually fewer than you think). Have the team agree on initial “Definition of Done” at the story and sprint levels. Then use Planning Poker to assign Story Points (SP) to the stories in the backlog.
- Prioritize the backlog: Now you’ve got Business Value Points and Story Points for each item. With those two values, you can then do some very simple math to arrive at a crude-but-useful Cost-Benefit Analysis (CBA):
BVP/SP=CBA
Simple and rough, but very useful to help prioritize the work quickly. So now, prioritize that backlog!
- This is also a good time for the team to start identifying the risks, dependencies and other considerations that need to be made transparent to the team and stakeholders before embarking on this adventure together.
If you’ve now got a prioritized and estimated backlog, the team can probably come up with a very very very rough release estimate of schedule and scope. This estimate will be woefully inaccurate, but should give everyone a sense of what might be possible. After 3 iterations, you can use your velocity data to revisit this release estimate.
Lastly, don’t forget about the regular care and feeding of your Release Plan: During each iteration, the team might have 2 release-focused meetings (sometimes these are called backlog grooming):
- Big picture backlog maintenance (can be done early in the sprint, and maybe everyone doesn’t need to attend this meeting as long as you have a good cross section of skills/views in the room). What does your velocity tell you about how much of that backlog might get done by what point?
- Top of the backlog maintenance so that it’s ready for the next sprint planning (1-2 days before end of iteration, everyone should attend)
Bon voyage!
