Joe’s Approach to Agile Release Planning

Agile Release Planning is technically not part of Scrum.  But I think almost all Teams need it.

As a coach, here are my thoughts on what Agile Release Planning should comprise.

For 5-7 months of work, this could be done in about 1 day (maybe into a second day).  With good enough quality to then start a Sprint a few days later.

I will explain release planning more in later posts.

I do NOT guarantee that release planning is needed in all situations, nor that this particular approach will work in all situations.  Still, I have done this now with lots and lots of teams, and so far all have found it useful.  My experience is that everyone I have done this with has liked it after they did it.  And thought it was worthwhile.  And actually did almost all of it (and almost all that it implies to me, but is not stated here).

1. Vision
2. Product Backlog
   • Roles
   • User Story Workshop
3. Business Value
   • BV Drivers
   • Priority Poker –> BV points
4. Effort
   • DOD
   • Planning Poker –> Story points
5. Risks, Dependencies, Learning, MMFS. Other
6. ORDER THE WORK
7. Make scope-date trade-off
8. Calculate the budget for the release (usually a simple calculation)

Then we have to talk about some other things, and see where we go.  For example, often we find that the skill sets involved need to change (as we now see the product or project differently).

Then we have to do Release Plan Refactoring every sprint, as things evolve.

As I have said elsewhere, the real value in doing this is NOT the ‘crappy’ estimates that the team arrives at after the initial release planning.  (They must be ‘crappy’ because the inputs are always insufficient.)  It is that everyone is now ‘on the same page’ about what the elephant is.  At least a whole lot more than we ever had before.  And I find that tremendously valuable.

Note: If they do really bad or no release planning, I think it ups the chances a lot that the stories are not small enough in the Sprints.  This means that lots of stories just can’t get to ‘done, done’ in the sprint.  So, good release planning is linked to having good sprints!  Now, this problem (stories too big) can be fixed later, but god, all hell is breaking loose then.

 

 

« « Joe’s Unofficial Scrum Checklist || You’ve got to find what you love (says Steve Jobs) » »