How to deliver a product release on time (for product managers)

For most product managers, a big product release is a stressful moment. The road towards it can also be very painful and usually isn’t without conflict. A lot of things need to go right and a lot of things can go wrong.

Does a mayor product release have to be so painful? The answer is NO. I’ll explain a simple method I use that could inspire and help your product operations step-by-step within 7 minutes. Your win: decrease in stress levels!

Prerequisites: I assume you have some experience with SCRUM/Agile methods.

The old way: why feature freezes are a bad idea

Although SCRUM is great for the incremental release proces, most companies still have big releases. Usually big changes in the product or features that change the user experience significantly. In my experience I’ve seen companies fallback to waterfall and feature freezes to manage big product releases.

What is a feature freeze?

A feature freeze is when product plans all features and to-do’s upfront a release according to what your stakeholders think is best at that time. At a certain date (which is communicated upfront) they ‘freeze’ the release. It basically means that everything that needs to be done for the release is set-in-stone from that moment till the actual release. Nothing can be changed, absolutely nothing. All stakeholders need to wait for the release to happen which can be weeks or even months.

This is why feature freeze is a bad idea

Most people can’t look that far into the future unless your company hired a bunch of fortune tellers. People are pretty bad at predicting the future. Their needs will change and so will expectations of a product release.
People are incentive-driven, not feature-driven because your stakeholders have their own targets, KPI’s, etc. Those are connected to the same important incentive: money. They won’t care about your feature freeze. They want you to reflect their incentives within any release. Incentives is what drives people. Freezing anything in such a way is flawed by human default.
They’ll want to break the freeze anyway if stakeholders need to move or change, they’ll bump into your freeze somewhere down the line. Now you’ve become a blocker for them to reach their goals. This will result in conflict. Spoiler alert: you won’t win the discussion by pointing at the freeze agreement. It will just make you look more like a product douchebag.
Breaking a feature freeze = recipe for turmoil when higher management actually breaks the freeze to get their way, prepare for turmoil within your team. You’ll need to start all over again to get into a new direction and freeze, resulting in confusion and (again) conflict.
Expectations will rise during the freeze mainly because of all the waiting. That will automatically result in them wanting to see very good results from the release. Ever waited in line for a long time and heard the phrase ‘this better be good!’? That’s exactly it and you just lost all control over managing those expectations. I’ll give it a 99% chance you’ll never meet those risen expectations.
The world around you is still moving and you’re trying to live in a bubble. You freezing means you just stand still for a while. But everyone else will move faster. While your industry is moving, your company should always be ready to adapt.

The main challenge with a product release

It all runs down to one thing: flexibility. Cranking out features isn’t your job. Reflecting value and improvements in product based on managed expectations and (customer) feedback is.

Most of the release will go according to what you planned upfront. It is the percentage of change requests within the entire release that result in significant disturbance, conflict, stress.

The bottom line is… We need a method that still controls the majority of expectations for the release but adds a sufficient amount of flexibility to provide the necessary breathing space to change while steering towards the same direction.

Introducing: the release bucket

The idea is as simple as a bucket… you create a bucket (= an amount of total story points reflecting a timeframe required to clear a certain amount of work). The timeframe is based on the average calculated sprint velocity of your team.

Example: the average delivery rate of the team is 40 story points on a 2-week sprint cycle. The big release has X features and all user stories combined are estimated at 320 story points. Resulting in a delivery date 8 sprints from now.

The bucket is then filled with user stories until the estimated story points reach the maximum of the bucket. Now it’s full and reflects a release you can do in the given time.

The release bucket is a calculated way to leverage SCRUM planning and executing bigger releases without breaking any of your operations or deployment cycles.

Overall structure

As you can see, it really looks the same as a basic SCRUM flow. The only big difference is the extra component between the backlog and the sprint. Let’s go through it bit-by-bit.

Backlog acts as a normal backlog. You collect all your user stories, (sub)tasks, etc there.
Release bucket this is where your collect all stories and tasks meant for the big release. Even if not estimated yet, put them in here if meant for release. This way you know what to estimate first in your next SCRUM planning and/or refinement session. Don’t worry about having too much at first, you can throw things out later. It’s about getting it in there, estimate and getting a clear picture how much work story points it is in total.
Sprint the only difference here is that the release bucket feeds all sprints when working on a release. You can’t pull anything directly from the backlog into the sprint when you’ve committed to the release. The sprint acts like a pump that empties the bucket.
Deployment as you normally would. If you want to keep features hidden from users before release without stopping deployment, use feature flags or feature branching. Whatever strategy your engineers like best. If you don’t know what that means, read my tech dictionary.

The problems a release bucket can solve

If you use this to its full capacity, you are able to tackle some general troubles:

Adds (reasonable) flexibility for changes which will make your stakeholders love you and buy you lunch every day!
Protects any current SCRUM operations so you can stay away from waterfall or mixing up other non-Agile methods. Your team will have a piece-of-mind.
Build-in stakeholder management Stakeholders can’t change anything without ditching something else with similar workload. They can’t add, only in-out swapping.
Better management reporting on progress because you only have to look at how many story points where cleared per sprint and velocity, progress is easy to understand for any management or stakeholder. You can use a burn down chart to keep it simple (Jira can generate it for you).

Implementing the release bucket (SCRUM)

Now let’s dive into the release bucket method step-by-step.

I want to re-emphasize one thing… This is only meant for a product release that can be considered as ‘big’ or ‘mayor’ for your company. Don’t use this for incremental sprint releases as it is overkill for that scenario.

Calculate your sprint velocity

It’s the most important part of this product release method. The analogy I use here: when you go from A to B on an airplane, you as captain need to know the cruising speed in order to know what your estimated time of arrival is. We’re basically calculating the cruising speed for the product operations.

The speed component in SCRUM is called sprint velocity. Most of you product managers probably use Jira. Lucky you because it generates velocity charts for you (if you did your sprint planning correctly). I would say you’ll need at least 3 months of historical sprint data to have a proper average on sprint velocity. The average is what you can take as speed indicator.

How to calculate sprint velocity yourself

If you use other SCRUM software without such a feature, you can calculate it yourself. Basically revisit your previous sprint data and calculate the average of the total story points completed per sprint from at least 6 sprints.

Important note: when completed story points per sprint fluctuates heavily (more than 20%), it indicates that something is off with estimating story points. A team with good understanding of SCRUM is recognized by stabilized sprint velocity. If you see this, revisit how your team estimates stories during planning (= task for your SCRUM master) and try to stabilize your sprint velocity first.

If you calculate the average based on too heavy fluctuated (= asymmetrical) values, your velocity indicator will be incorrect.

Gather data from your feedback loops

Once you start filling the release bucket you’ll get a first glimpse of the release scope. Although you probably have your roadmap, it’s important to check-in with your (customer) feedback loops. You need to make sure you’re working on the right stuff.

Being data driven means you gather the feedback data and check the references with your user stories. Do they seem to correspond? If so, you’re definitely on the right track.

If not, review the first draft of your release bucket and ask yourself: is this really reflecting the user value that has the highest priority now? Remember, it’s about prioritized value, not about wanting to cramp in as much as possible for a release.

Start grooming the bucket (like hell)

Management and stakeholder would want to know how long it will take to deliver the release. The biggest mistake made here is that product managers want to satisfy the question with an answer based on a ‘hunch’. That never works out well.

Instead, show them what your doing with the release bucket and take time to proper estimate everything. When you start filling that bucket, take the planning/refinement sessions to start grooming the bucket. Really maximize those meetings to get as much as possible estimated.

This is how you get it done the fast way:

Estimate the simple things first just to get you on a roll and make some progress fast.
Create spikes for stories unclear to figure out the actual execution. Pull those spikes in your current sprint (if spart time available) or next sprint. You need clarity fast to estimate.
Don’t forget dependencies when you need third-parties to get certain data, permission, etc. Those subtask could already be picked up as soon as possible to prevent blockers.

Align product release with stakeholders

As said before, stakeholders want their share in the release. And everyone is equally important, right? As much as you want that to be the truth, that’s not reality.

Product is balancing a lot of different needs to serve the overall company goals. Balancing means using the available time and resources that does that in the most effective manner:

Review if the release aligns with the stakeholder’s needs and correspond with given data (no requests without data the stakeholder proving there is actual need for it).
Align with stakeholder targets, KPI’s, etc remember the incentive-driven part? Stakeholders will only run for your requests when their own incentives are connected to it.
Let stakeholders commit resources part of your Definition-of-Done will be your stakeholder testing or using certain parts of the release. Make sure they commit to giving you the resources in time to prevent delaying any execution. They need you as well as vice-versa.

Stakeholder flexibility

Make stakeholders aware that changes are OK to a certain degree. The rule is simple: if a stakeholders want to add a user story, they need to take out another (which hasn’t been executed yet).

There are still some requirements before you can OK the change request:

They need to prove the new story has user-value based on data.
The story needs to be of similar size (= story points) from the one they take out. Keeping the release bucket the same in size.
They can’t remove a story from another stakeholder or they need to get their full consent.
You find the request reasonable in it’s entire proposal. You have the final call.

How to use this mechanism to your advantage as product manager:

You basically ‘negotiate’ the change. If you arrange a change of stories for them, you can get something in return later. Data, that idea you wanted to test, etc. No such thing as free lunch.
Happier stakeholders just by providing them some breathing space.
You saying NO gets a softer landing. Because you provided the breathing space, it’s easier to accept that some requests are really not meeting value and scope requirements. Less conflict.

Resource planning

Now you’re almost there. You got a release bucket almost finished, aligned and ready to communicate an estimated release date. But don’t forget: people go on holiday, get sick, etc. In our airplane analogy, we need to factor in the ‘turbulence’ that can effect our cruising speed:

Check with every team member for planned vacations, off-time, etc. You can use a time tracking tool to fill in the gaps and see where team members are absolutely needed. This prevents resources from being unavailable while you could’ve anticipated on it.
Check for ad-hoc extra capacity. If your company works with external resources that are familiar with jumping into your operation, it might pay off to check with them if there is a possibility for extra resources when you need to fill gaps.

Conclusion: being on time remains really hard

With any big product release, time is always against you. I’ve had my fair share of being on time and being late for a product release. It’s part of the game. It takes a lot of practice with your team to get it right.

A stable sprint velocity and being persistent by focused direction will go a long way.

The method I presented is simple to implement but this isn’t a holy grail for all product releases. Hopefully it gave you more tools and inspiration about how to get your product release out on time. It will definitely help you minimize any delays as much as possible and provide an array of assets on stakeholder management, reporting, etc.

Bonus tips

If you’re still reading, you’re a pretty hardcore (product) manager. So I’m throwing in something extra for you guys:

Do your release preferably in the middle of a sprint, not at the end so you can use the remaining part of the sprint to do some bug-fixing and needed polishing. Don’t plan it.
Relief your team from the release pressure another function of not planning the entire release sprint is to relieve some pressure from the team. They already where under a lot of pressure probably right before the release. Let them fix and polish in a more relax mode.
Towards release, try less meetings Although must SCRUM fans would scream havoc, you need to focus on the release. If you have limited resources, meetings are costly. Try leaving out team members that are not needed or keeping meetings really short. Especially engineers would want to focus in silence on solving problems than being in a sprint planning.
Pay attention in your retrospective when pressure is up, people will feel and act upon it. Pressure usually means stress. Stress is an impairment to the brain which leads to poor decision making, decreased execution and a whole list of bad things. Some stress is ok but it can get too much quickly. Retrospective is a great moment to put it on the table and check if team members are taking care of themselves. You as a leader are responsible for your team’s work-related wellbeing.

Liked this article? Send it to your colleagues or business contacts if you think they can use some inspiration about product releases.

How to deliver a product release on time