By Lyssa Adkins
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.
