Two Tips to Help Product Owners with Release Planning

3 June 2008

Lyssa Adkins
Agile Coaching Institute

Tip 1: Don’t let dependencies dictate when your team delivers value

Things have been going fairly well on your agile team. The team has been producing value at a regular cadence; the team members are actually working together and producing more than the sum of their parts. The team has a good idea of how much it can get done in a sprint (its velocity). The team is 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.” As the product owner, what do you do next? It’s time for release planning.
 
Hopefully, your agile coach has experience with release planning. If not, stop reading right now and bring in someone who has done this before. Release planning is not something one can learn solely from reading a book or article.

Let’s assume, though, that your coach knows what she is doing. She walks the team through release planning, so that the team members understand what they are building, have calculated the team's velocity, and have sized all the stories in the product backlog. The team members 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 far from done. One large piece remains: choosing which stories go into which sprints. 

Here’s the basic idea: stories are added to sprints until the sprint is “full” based on the team’s known velocity. How do you determine which story goes into which sprint, though? The most important consideration is business value. The goal of agile is to deliver the highest business value items first. 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.
 
Let’s assume you have ordered the stories in terms of business value. Next, lay your stories into sprints starting with the highest business value story first, then the second highest, then the third, and so on. It is important you do this step first, without letting any other considerations influence the order, so that you are clear on the business value priority.

Once this is done, the next step is to work with the team and agile coach to consider all those other things only they know about: things like dependencies, both technical dependencies and dependencies on other people’s availability and their expectations. But – and here’s the trick – don’t sit back and let dependencies dictate when you do a story. While some technical dependencies may be hard dependencies that truly can’t be moved, you should. challenge all technical dependencies. Often when a team thinks about it for a while, in light of the business value they could be delivering, they realize a hard technical dependency is not as rigid as they first thought. It’s rare to find a non-technical dependency that is a true roadblock. You should push back on all non-technical dependencies. Strive. Try. Endeavor to deliver the highest business value items first – 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. While it might be the only choice, or maybe even the “right” choice, doing a lower value story earlier is counter to the main goal of Agile. And, if your project is as 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.  

Tip 2: Sanity check your release plan and sell it

After you have the stories laid into sprints, you can look at the release plan in a couple of different ways to see if it all makes sense. Partner with your agile coach on this. The two of you together have the insight needed to do this. Then, the team needs to weigh in. Remember that. The team always needs to weigh in.

On to the sanity checks. First, focus on one sprint at a time. Ask yourself this question about each of the next few sprints:

  • Am I asking people to do too many things in this sprint? Are there too many topics to focus on?
  • Is there an overload on one or two people with a certain skill set? Or, are we so heavily focused in one area that some people on the team will have “no” work? (Hint: this can be solved for over time by making room for the team to naturally cross-train.)
  • Are all the “outside” things lined up, such as people you need to collaborate with, their managers, alignment on your approach or philosophy, etc.

Once you’ve done this and made adjustments at the sprint level, expand your focus again. Look across the whole release plan and ask yourself this, “What are the main storylines happening throughout the sprints and at what points does my customer get value?” Adjust your plan until you think you are delivering the most value in the fastest way possible. 

After that, create your elevator speech on the release plan. Get really good at telling the story of what the team is creating and when it produces value. Get good at doing it quickly – remember that this is an elevator speech. Why get good at the elevator speech? Your team needs you to be the heat shield for them. One way to be the heat shield is to deliver this speech to your sponsor(s), other stakeholders, people who have other projects that might derail yours: vendors, venture capitalists, anyone who cares. Sure, some people will want to get deeper and, for them, you can unveil all the detail. Many others just want to be “sold” – they want to know that the team has it under control. This is one tool you can use to demonstrate that control, create alignment, and clear the way for your team to work.

And, remember that great work is never done. You will inspect and adapt the release plan with each new sprint planning session as you see what the team can bring into the sprint and what doesn’t work anymore. You will also adjust the release plan as the world around you changes. Business value priority, for example, will change according to market pressures and external forces. Let this ripple through your release plan as it happens. Just as the sprint plan always reflects reality, so, too, should the release plan.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (1 ratings)

Comments

Harry Long, CSP,CSM, 6/11/2008 2:06:55 PM
I find that the team I have is working very well with estimation, providing a balance of Business Value and Technical stories in order to minimize the problem of Technical Debt.
Release planning is another thing altogether, and we are trying to tackle that. All in all, a very good article - although I find the need for Business Team education is a bit light in Scrum and sorely needed.
Piotr Uryga, CSM, 6/12/2008 9:17:05 AM
I have to say, that preparing initial Release Plan before meeting with the Team at Release Planning meeting is kinda interesting idea. I don't get one thing: how can we laid out stories in Sprints when we don't know their size yet ? Do You mean simply getting to the Release Planning meeting with prioritized backlog ? Because this seems quite obvious.
Lyssa Adkins, CSC,CSP,CSM,CSPO,REP, 6/12/2008 9:46:27 AM
Piotr:
I might be misunderstanding your question. Please correct me, if so. The team would still size the stories in the backlog. Everything I propose in this article happens after that. The insight most product owners I've worked with get from the content of this article is: If I (product owner) have priorities according to business value clearly aligned to sprints first, then when I make compromises due to dependencies I 1) know I've done this and 2) know what I've given up. And, along the way, the conversations with the team have become deeper and we all have a better understanding of the release plan.
Piotr Uryga, CSM, 6/13/2008 11:05:16 AM
Yes, the team would still size the stories in the backlog, but for me it's nothing new.
It's not that You misunderstood my question - probably I'm missing the point.
Here's how I understand Release Planning:
1. PO (Product Owner) prepares initial Product Backlog.
2. PO sets priorities assigning business value to all Product Backlog Items.
3. PO meets with team, we have Release Planning Meeting:
a) PO describes highest priority feature, discuss it with a team, estimation is done.
b) PO describes next highest priority feature...
4. We have stories estimated, PO with a team creates initial Release Plan, measuring Velocity and putting in the first Sprints highest priority features eventually changing order, due to dependencies.

I simply don't get Tip1. Do You mean, that this first step, a.k.a. laying out features in order based only on priority should be done by PO during Release Planning Meeting ?


Lyssa Adkins, CSC,CSP,CSM,CSPO,REP, 7/30/2008 12:31:10 PM
I have encountered a number of product owners who think about business value, dependencies, political priorities, and more all together when they start to slot stories into sprints. If they do this, they never have a clear read of pure business value and they are not aware of the sacrifices they have made. That's the only tip here: focus on business value alone, first.

You must Login or Signup to comment.