Releasing the Product for Scrum Masters
One of the most important milestones any project will ever have is finally releasing their product and putting it out there. It’s the fruit of those countless days and nights of ideating, analyzing, planning, building, and testing – with bumps along the way. A first-timer might think, much work has been done, so shipping it out shouldn’t break a sweat, right? But anyone who has been part of a product release at least once already knows: the pressure is far from low. We’re talking about a product that will be subject to public scrutiny; hundreds of users could find things the team couldn’t (given their project capacity and timeline). And in reality, anything could go wrong before the product release, regardless how meticulous the planning went.
As a Scrum Master, it’s one of your responsibilities to help your team navigate through the trying times of releasing the product. And, as with anything, it’s best to be prepared from Day 0. This can be done by helping the team on how releases are done in an Agile setting, and what they need to know to best handle it.
Releasing the Product in an Agile Project
In traditional software development projects, the product is released as a whole towards the end of the project. Agile does its product release differently – “releases” being the more accurate thing to say. One of the principles of Agile states the following:
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
Agile practitioners believe that the best way to improve and reach a product’s full potential is getting as much feedback as possible. That’s done by releasing early and releasing often. Doing this will require effort in planning, communication, and implementation. It’s important to have the team work closely with the customers in deciding which features to develop and in what order the features will be released, and how often this will be. This is to avoid any confusion or miscommunication of expectations and capacity.
The Product Roadmap
Every team’s dream is to be able to seamlessly release their product to production. By seamless, we mean having as little failure as possible. In order to achieve this, teams should plan for their releases and the tasks they need to do to reach their release goals.
At the early stages of the project, after the team has decided on their Product Vision and the main product features, the Product Owner should plot them out in a Product Roadmap. This is simply a high-level timeline of what will be released when. The Product Roadmap depicts the journey the product will make as features are added and changes are made. There are varying formats of a Product Roadmap, but the most important items to be mentioned in each milestone are release goals, the date of the release, and the features to be released.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
The Release Burn-down Chart
Because being Agile is about releasing early and releasing often, planning should be done for each of those releases in the Product Roadmap. Part of release management is tracking progress with a Release Burn-down chart. Much like a Sprint Burn-down chart, the Release Burn-down chart depicts the remaining work to be done for the release over time, from Sprint to Sprint. Tracking with a burn-down chart has the benefits of being able to visualize where the project is and how they’re doing against the budget. This information helps the team decide the next steps on what they can do to make ends meet, whether it’s getting more team members onboard, removing or prioritizing features to release.
When to Release the Product
A product increment is called such because it brings the product closer to its vision. In theory, the team should come up with a potentially releasable product increment at the end of every Sprint. This means that it simply needs to be in a state where it can be released anytime, should the need arise.