Release Planning
As a Product Owner, you are responsible for managing expectations of customers, users and other stakeholders. You are also responsible for Product Backlog Management, for deciding that to built when and what not to built. Also, you'll need to decide what to deliver (release) to customers/users, in what order to deliver to customers/users and when to deliver. So, as a Product Owner, you will need to have a release strategy and release plan. In this blogpost, we'll therefore cover 10 tips about Release Planning! I hope you enjoy them!
10 Tips for Product Owners on Release Planning:
1. Focus on goals, benefits and results
When planning for releases, there is a lot to take into account as a Product Owner! Is there a market opportunity that can be seized? Are the users ready for it? Can you eliminate certain risks by releasing on a certain moment? And many many more. When you're planning your Product releases, start by identifying goals, benefits and results you want to achieve. Many Product Owners out there are creating a release planning which is focussed around features. This is nice of course, since it offers insights in the development of the Product. What we've experienced to be even more valuable is to design a roadmap around the goals or targets you want to achieve and to show what features are contributing to a certain goal. A nice example of a Goal-Oriented Product Roadmap has been created by Roman Pichler, check out this link for the GO Product Roadmap template.
2. Take dependencies and uncertainty into account
Besides planning for goals, it's really important to take dependencies and uncertainty into account. There are different tools and formats you can use, what I've used in the past was the Program Board or Dependency Board as shown on the Scaled Agile Framework website. This helps in identifying dependencies which are especially relevant when you're working with multiple Development Teams. Another way to make dependencies visible is by using a Story Map for example. Identifying dependencies in your release plans makes it easier to collaborate with the Development Team and your stakeholders and to reorder the Product Backlog in a meaningful way.
3. Release early and often!
What I always share in the Professional Scrum Product Owner Trainings when we talk about Value, there is one thing that you as a Product Owner must remember: “You have to release a Product to customers and users, in order to find out if you have delivered value for them!”. Unfortunately, I encounter a lot of Product Owners in daily practice, who think that ‘working on the Product for just a couple more Sprints’ will create a Product that customers/users will certainly love. Often, this results in a lot of disappointment… So, start validating value, by releasing to your customers and users early and often!
Many Product Owner though 'rather' release a couple of times a year, doing big bang releases. This is often done in organizations 'because doing a release is difficult'. In most situations we've faced, this is true! It is often hard to release! But the problem is, if a release becomes bigger and you release less often, it stays a difficult thing that people want to avoid! So, in order to make it easier, you have to do it more often! When you start releasing more often, people will start to think about making it easier (by automation for example) but they will also gain experience, which helps them in doing it better and faster. So stop doing big bang, low frequency release and start doing smaller releases more often!
4. Only release work that is 'Done'
In many organizations, a lot of teams are releasing 'undone work'. This 'undone work' is work that is released to production, but which isn't delivered conform the Definition of Done. This creates technical debt, which costs you a lot of time and a lot of money to fix. It will cost you valuable time which you can't spend on delivering value for customers and users! So respect the Definition of Done!
5. Get ownership over the release process
Get ownership over the release process. Or better said: Support the Development Team in getting ownership over the release process! In many organizations, doing releases (to production) is something that is 'owned' by a department such as Release Management or Release Coordinators. When the Development Team doesn't have ownership over the release process, it is often more difficult to do a release and it often costs you as a Product Owner valuable time. What I've experienced to be very helpful in the past, is to provide the Development Team with ownership over the release process. This is something nor you, nor the Development Team can often decide by yourselves. So what you can do as a Product Owner, is to create transparency about this topic during the Sprint Review for example. When your stakeholders are asking you: "How can we become faster?" or "How can we deliver more value?". Then help yourself and the Development Team, by raising awareness about the release process.
6. Improve the release process continuously
There is more to Product development than delivering more features and functionalities. As a Product Owner, you should be aware that improving the release process will support you in delivering more value for your Product. So collaborate with your Development Team to automate the release process, automate tests, automate deployments, etc., but don't try to do it overnight though! Spend a little time on improving the release process every Sprint, so you can deliver both customer value and improve the team.
7. Create at least one releasable Increment per Sprint
In many organizations, teams are working very hard on a lot of different things in a Sprint, this often results in the team having 100% of the work, 80% done. Bottomline, this means that a lot of work has been done, but no value for customers and users has been delivered, since it's not finished, it's not 'Done'! So help the Development Team by offering focus, with a Sprint Goal for example. Support the Development Team to deliver a Done Product Increment, as early as possible in the Sprint, which is helpful, since you will at least end up with one Increment that could be released if you'd want to.
8 & 9. Don't release for the sake of releasing + Make releasing a business decision
In some organizations there is a centralized release calendar in which everyone has to participate. This release calendar is often planned for monthly or quarterly releases to production. On the other side, more and more teams are gaining ownership over the release process, making it more decentralized. In both situations I've met teams who were 'releasing because we have to release every Sprint'. This is not true! Yes, from a Scrum theory perspective you want to have a releasable/potentially shippable Product Increment every Sprint. Wether or not you will actually release this Increment to production, should be a business driven decision, not driven from a technical perspective, but from a business perspective!
10. Take the context and your audience into account
When, how often, to whom you release an Increment depends on the context you are working in and on your target audience. In many organizations, I see that Continuous Delivery is becoming very popular and a lot of people want to be able to do a new deployment of software practically every minute. Of course it is very helpful to be able to release with little effort, with the push of a button. Wether or not you will actually use it, depends greatly on the context. In some contexts (like Amazon's), releasing multiple times a minute seems to have a lot of value. In other contexts, when working on HR- or payroll-systems for example, a release once a month might be enough (at least, that was back in the days when I developed such products).
Also check out these other tips for Product Owners!
Holy Guacamoly! Are there even more tips for Product Owners? Yes there are! We've described 60 more tips for Product Owners, to help you to become better in your role! We've defined 7 aspects of Product Ownership on which we have interesting tips to share with you, so check them out:
