Thursday, August 25, 2011

Joe's Approach to Release Planning

Here's what I think Release Planning should comprise.  For a 3-6 month release, most teams could do this in about 1-3 days.  With good enough quality to then start sprinting the next day.

I want to say quickly that we don't just do the initial Release Plan.  We also do Release Plan Refactoring every Sprint. (And possibly some Sprints there are no changes.) The adaptiveness of agile release planning is perhaps its most essential aspect.

I will explain release planning more in later posts.

I do NOT guarantee that release planning is needed in all situations, nor that the approach will work in all situations.  Still, I have done this now with many many teams, and it seems to have worked with all of them.  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
    • What is BV for this project?
    • Priority Poker --> BV points
  4. Effort
    • DOD
    • Planning Pokers --> Story points
  5. Risks, Dependencies, Learning, MMFS, Other
  7. Make scope-date trade-off
  8. Calculate the budget for the release (usually a simple calculation)
(Note: MMFS stands for Minimum Marketable Feature Set. See Software by Numbers by Denne and Cleland-Huang.)

Then we have to talk about some other things, and see where we go.  For example, sometimes we find that the skill sets needed are different (now that we see the product or project more clearly).

Then we have to do Release Plan Refactoring every sprint, until the plan is more solid (sometimes it is always being improved). 

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.  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 and most others find that tremendously valuable.

Note: If they do really bad or no release planning, I think it increases the chances a lot that the stories are not small enough.  This means that lots of stories just can't get to done, done in the sprint.  So, in that and other ways, 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. Do Scrum professionally from the beginning.

Other posts on Release Planning:


Russ said...

Good list. I would add a bullet to discuss resources dedicated to the release (in addition to resource planning during the sprint).

Joe Little said...

Hi Russ,

Agreed that that happens. Umm, to me it is not "release planning". Reviewing the resources is one of many many things we do to start the effort.

Still, I guess my difference is mainly semantic. Yes, we definitely review the composition of the team now that we know more, and sometimes make adjustments.

Regarding 'resource planning' during the Sprint...I would hope that the core team (the Scrum Team) is stable. This is important, and of high value. But sometimes the 'chickens' supporting the Core Team must change a bit. Is that what you meant?

Thx, Joe