Release Planning: Don’t let dependencies dictate when your team delivers value

LYSSA ADKINSSEPTEMBER 26, 2007

You’re the product owner and things have gone fairly well on your Agile team.The team has been producing value on a regular cadence; they are actually working TOGETHER and producing more than the sum of the parts.The team is getting an idea of how much they can get done in a sprint (their velocity).They are now asking, “When does this end?” or “When are we going to release this stuff?” or “I know we’re going to California together but I’m not sure if we’re getting there through Texas or South Dakota.”What to do next?One way to give that light at the end of the tunnel is Release Planning.

Hopefully, your Agile Coach has experience with this.If not, stop and get someone who has done this before.It is not something one can read from a book and facilitate a team to do – at least, not well. 

Let’s assume your Coach knows what she is doing.Through her facilitation, the team understands release planning and has sized all the stories in the product backlog.They are feeling good because they now understand what work is left – they at least know if they’re going through Texas or South Dakota on their way to California.But, the work of release planning is not done.Now, comes the moment of truth.How do you choose which stories go into which sprints – at least as a starter so the rest of the team can collaborate with you on it?

My favorite visual of this can be found on page 6 of Mike Cohn’s Agile Estimation and Planning deck, slide 12.There are actually more recent decks on this topic on his website, but they don’t include this specific graphic which teams seem to “get.”So, go look at page 6 of the deck.

Look now.  Are you back?

OK, you get the basic idea – stories get put into sprints until the sprint is “full.” HOW do you determine which story goes into which sprint, though?Only one answer to that:based on highest business value.The goal of Agile is to deliver the highest business value items fastest.This requires you, product owner, to order the stories according to business value. A great discussion of how you determine business value can be found in Mike Cohn’s Agile Estimating and Planning book (see link to it at the end of this post).

So, you have them in business value order.Now, lay your stories into sprints starting with the highest business value one first, then the second highest, then the third, and so on.You’ll also need to consider things like size and dependencies (both technical dependencies and dependencies on other people’s availability and their expectations).But – and here’s the trick – don’t let size and dependencies dictate when you do a story.Strive, try, endeavor to deliver the highest business value items fastest – always.If you decide to do a lower value story over a higher value story because of a dependency (like someone else’s expectations of your “schedule” or a key person’s availability) at least you know you’ve made a sacrifice up front.

Call it out.Make it clear.It might be the only choice, maybe even the “right” choice but doing a lower value story earlier is counter to the main goal of Agile.And, if your project is so all-fire important as your sponsors tell you it is, how many of those dependencies do you think they can alleviate?Probably most of them.

Next time…”sanity” checks for your release plan.OR…what to do after the stories are laid into sprints.

For a fantastic book in the subject, get Mike Cohn’s Agile Estimating and Planning .Better yet, buy it through my list on The Road from Project Manager to Agile Coach and automatically make a donation to National Public Radio.