Agile Release Planning: Have a Goal or You Won’t Reach It
Agile Release Planning is Often Overlooked
Most of the Scrum and Agile training I have experienced focuses on processes and sprint rhythm of scrum, as their focus is on the development/engineering role. The focus is on the process of sprint planning, backlog grooming, the definitions of ready and done, daily standups, retrospectives and having the most productive team. The focus is often not on the overall goal with the customer benefit and business impact. The team is mired in the necessary activities of the sprint. Agile release planning, the determination of the business impact expected and the overall plan (scope, schedule, and resources) to accomplish this is overlooked.
Five Levels of Agile Planning
Releasing an agile product requires having a long-term goal and a structure of shorter-term finite chunks. The Product Management role and Product Ownership role work together to maximize the business impact and the effectiveness of the team.
To be effective, you need to plan at all five levels of Agile planning:
- Product Vision – A long-term vision or direction for the product. It may not be achieved within the timeframe of the roadmap, but is the guiding principle of the product.
- Product Roadmap – A rough timeline for features and epics that bring value to customers.
- Release Planning – Specific epics and high-level features that will combine, when delivered, to a substantial business impact. The release is the next major bucket of work to be taken on by the team.
- Iteration Planning – Plans and commitment for what will be delivered in this iteration/sprint to meet the release goals.
- Daily Plan – The daily plan for each individual, often communicated in the daily standup.
Note that “release” as we’re talking about this is a package of functionality that has a defined business impact. A release will have marketing and other events associated with it to drive the business impact through the entire organization. On the other hand, teams may deliver code continuously or drop code to other internal groups at defined intervals and call these drops “releases.” The latter is not the business impact type of releases that we’re describing here; those are more about the internal engineering practices. Release goals focus on the external business impact.
So You “Went Agile”… Now What?
I’ve worked with more than a few engineering organizations that “went agile.” I asked one of the leader engineers what Agile meant to him. He said, “We work on the code until we get it right; then we tell you, and we ship it.” The management view was different. Management had expectations on when the code would be ready, but these were not met. The tension in the team started to rise after three or four sprints when the product did not have sufficient functionality for the market to care.
The product wasn’t meeting its business objectives, and almost everyone in the company was unhappy. Eventually, the company abandoned the project in question because it had slipped to more than three times beyond the expected timeframe and did not meet customer needs. This was a case where iteration and daily standups were happening, but did not meet business objectives because of the lack of the larger plan, the first three items in the list above. Don’t follow the anti-pattern of this story.
Product Management’s Focus
Much of the Product Manager focus should be on the first three items in the list above, with some interaction on the iteration and daily level. The Product Owner focus is the inverse: heavy on the daily and iteration, but active and knowledgeable in the release plan. The Product Owner needs to communicate these three higher levels in the list to the team on a daily basis in standups and sprint goals.
Let’s look in more detail at what the Product Manager needs to do beyond the Agile release planning level and above:
- Have a company vision. As the Product Manager, you may be a participant in this discussion, but it is often handed to you as a framework to work within.
- Have a product vision and roadmap that align with the company vision.
- Have release goals that bring clear business value, whether it be new functionality, better architecture, or paying off technical debt. Be clear on schedule, even with uncertainty, scope and likely schedule.
- Have both management and team buy into the release goals.
- Make the release goal visible. Have it written on the Scrum board, wiki page, or wherever it can be seen by the entire team.
- Have a release burndown chart to make the progress to release goal visible. This may require that the team estimate the size of epics and stories that are that are more than a few sprints out.
- Get customer feedback on each sprint, if possible, to make sure you are on track with expectations and have a viable product. The team needs the feedback, and your responsibility is to be the voice of the customer. Work both to represent that and even have actual customers use the product and give feedback.
- Don’t be afraid to change your backlog or even modify your goals or schedule as you learn more from customers. That’s the point of Agile.
- Communicate changes and the “why” behind those changes so that the organization, from the team to management to sales to marketing understand the overall goals, value proposition, and what you learned that caused these changes. Nobody likes surprises, and communication and transparency avoid surprises.
Two Suggestions for Product Managers
I have two other strong suggestions I give Product Managers to make your release plans effective. You may not be able to attend every standup, but do be present for the backlog grooming so that you can give the customer context and participate in the backlog tradeoffs. Be present and active in the sprint close, as this is when you can relate the activities of the sprint to the higher-level release goals. Both of these meetings are great times to bring customer feedback and market understanding to the team.
Your role as a Product Manager and Product Owner is to lead your team to have the most favorable business outcome in the most efficient way.
Agile release planning gives that longer range vision which will motivate your team, your organization, and customers. Poorly written or communicated release goals are an invitation to disaster. Join the 280 Group course, Agile Excellence for Product Managers and Product Owners which teaches techniques for all of these levels of agile planning, it also gives you the skills to be an effective team leader to deliver successful products. Agile release planning is a major item we teach in the class to help Product Managers and Product Owners be team leaders and unify their development team and organization around the product goals.
Moving Your Organization to Agile Release Planning Is Not Easy
I had this article reviewed by agile Product Managers and Product Owners before it was posted. Many of these people experienced the introduction of release goals as well as roadmaps into their organizations: they told me some of their painful stories on the path to success.
Here were the top four impediments to doing Agile release planning:
- It’s tough to find time as a Product Manager/Owner to think long term. There are many immediate and urgent demands on your time, and it is difficult to push those to lower priority as you focus on what’s important. The 280 Group’s course People Skills for Product Managers and Product Marketers teaches many of these skills to be more effective.
- The development team may push back that they can’t see that far into the future. Agile release planning may not have been done before. You’ll need to guide them to develop a shared vision and goals so that they can work with you. Once there is transparency and honest accommodation of changes from both the Product Manager and development team, the value of release goals will be apparent.
- It’s difficult to find ways to validate the release goals with customers. Once you have the release goals and high-level stories, you should test these with your customers. There’s never enough time to do this, but it’s essential to focus on this so that you can represent the true voice of the customer on the issues. Have representatives from the development team participate with you in the user feedback so that they can experience it directly.
- The company culture may not be set up for transparency yet. It’s typical that only the development organization moves to agile values early in agile adoption. You’ll be pushing these values into the rest of the company and may need to explain yourself and get the backing of your development team and other agile adopters.
The key is that you’re not alone in these challenges. Knowing that they exist and that others have overcome them should help you to keep your focus on the ultimate goal: a successful product.
If you would like to learn more about Product Management role in an Agile environment, take our new training course: Agile Excellence for Product Managers and Product Owners, available in-person or as an online course.
Download the first two chapters of Agile Excellence for Product Manager here:
Here Are Two Quotes That Inspire Me When Planning Is Difficult
To achieve great things, two things are needed; a plan, and not quite enough time. – Leonard Bernstein
In preparing for battle I have always found that plans are useless, but planning is indispensable. – Dwight David Eisenhower
Meet the Author
Chuck Myers is a Principal Consultant and Trainer for the 280 Group. As a Product Management veteran, manager and mentor of Product Managers, he has extensive experience turning new concepts into robust products and then bringing them to market. In his 40-year career, he has worked as a developer, architect and Product Manager. He is very active within the Agile community and helped contribute to the development of the 280 Group’s new Agile course.
Senior Principal Consultant and Trainer