Building a Quarterly Release Plan

Part I - A simple tool to answer one of the toughest questions we face

How much should we commit to this quarter?

This question is always tough to answer, and a daunting one. As we approach our next quarter, there are still many unknowns, and our backlog looks more demanding than ever. When tackling this question, product teams often result to T-Shirt sizing, rules of thumb and gut feelings to decide how much to take on. And as the list of epics stacks up, the challenge is knowing when to stop adding items.

Below I offer a super simple tool and framework to take you through this process. I've developed this process in collaboration with my engineering and product peers during the first years of my career, and have used it ever since, to help us answer the following questions:

- How much work can we take on this quarter?

- Which epics can we get done?

- How do we communicate our decision and conduct prioritization with stakeholders?

And later in the quarter:

- What are the items we need to work on next sprint?

- Can we take on this a new feature, and on expense of what others?

- Are we going to meet our deadline, and when should we communicate change or delay?

The tool is a super simple excel sheet which has 2 basic elements - a list of tasks to be completed, and story points per task. So far so good, right? The key is to use a simplified gantt-like view which sums up the points per sprint, and for the entire quarter. Not rocket science, nor is it Nobel Prize material, but it works, and its simplicity makes it super easy to introduce to your team.

Why use this tool?

Pros:

Quick and simple to learn, set up and use
Can accommodate any roadmap and planning methodology (we will use epics, user stories and story points for illustration purposes only)
Can theoretically be done for any kind of team (although I only ever used it for engineering teams)
There's plenty of room to change and adjust as needed
It really works, and...
It's free :-)

Cons:

Does not sync with JIRA or any other project tracking software, which creates maintenance overhead if used throughout the quarter
Assumes homogeneous teams, i.e. that each person can do any type of work, or at least, that there is enough redundancy between different expertise. When this assumption doesn't hold, some more attention is needed when assigning tasks to sprints

Ready to start? -- You can already download a copy of the tool from here.

Here's the basic layout of a quarterly plan:

Basic layout for a product planning tool

How does this work?

1 - Set up the sheet for next quarter

Adjust your calendar - list months and sprints (we'll use 2-week sprints but can align with any sprint cadence)
Add each sprint's capacity in line 3. You can use whatever capacity method you wish. Account for holidays and all-team events by reducing sprint capacity accordingly. Don't worry about getting it exactly right!
C3 will sum up total capacity for the quarter. Line 4 will sum up total task estimates for quarter and per sprint.
In our example, we have six 2-week sprints over 3 month (note that some quarters will have seven 2-week sprints!). Our capacity is 20 story points per sprint, and since it's Q1 there are no major holidays to account for (at least not in the USA), which leads to a total quarter capacity of 120 story points.
We also add a Q2-20 column (J) for rollovers and out-of-scope items (see below).

2 - From Roadmap to a Plan

Always start with a roadmap. To be clear, this is NOT a roadmap, but a release plan for your next quarter.
Add all the epics you believe you can complete to column A. Since each one you add will require further work, you may want to start with only the top priority ones, and add more if you find you have available capacity.
Together with your Engineering Lead, break down your epics into user stories, and add them to column B. For example, if you build a log in page, your user stories may be:
- Create a log-in form
- Authenticate the user against some backend user list
- Start a new session
- Create or update a cookie
- Move on to the next page
At this point in the process, don't worry about optimally slicing your USs. Just make sure you account for everything that needs to be done to deliver the full scope of the epic.
If you are unsure how to break down the epic to user stories, you don't understand well enough what's the expected outcome. Go back to the drawing board and come back when you do :-)

3 - Estimating

One by one, discuss each US with your Engineering Lead until you agree on scope and deliverables per US.
Ask your Engineering Lead to provide a rough estimation per US, and add it to column C. If you disagree on the estimation, it probably means you each understood the US differently. Discuss this until you are aligned.
Don't forget to account for overhead such as integrations, QA, documentation, deployment etc., but avoid creating dedicated line items for them.
DO NOT over analyze and DO NOT attempt to slice any further. At this point in the process, doing either one will only increase your error, rather than decrease it. This has been my experience throughout my career, and is supported by a number of researches.
I always lean towards taking the reasonably high estimate per user story, as added buffer.
If you're not sure how to estimate the work, time-box it (i.e. determine what is the maximum capacity you are willing to spend until you rethink the story).
You should never find yourself in a situation where you can't even time-box a task.

4 - It's Planning Time!

Now that you have all your epics broken down and estimated, it's time to make some hard choices. And here's how the tool helps you:

It is very likely that by now your total estimation (cell C4) is greater than your available capacity (cell C3). In this case, GSheet conditional formatting kicks in to highlight this for you.
The formula takes into consideration a 30% buffer to highlight total estimation which is greater than 70% of your capacity. I found that a 30% buffer is a good cushion with every team I worked with, but this can change for any of the following reasons:
- Very high volume of unknown work expected in the quarter (solution - create an epic for this and time-box it)
- You have low confidence in your ability to estimate your user stories
- You are concerned about unpredictable capacity changes (e.g. company restructuring, employee churn, reliance on outsourcing with questionable budget, etc.)
You can use any buffer you want by changing cell M1.

Here's how it may look:

At this point, you can decide between:

Reducing scope within one or more epics by removing some of their USs. Do this by moving their estimations of to the next quarter (column K). This is when you actually define the MVP for this epic.
Removing some epics altogether - do this by moving all of the estimations to column (K).

I would generally advise to opt for postponing whole epics and cutting back on scope within epics. This will allow your team to focus on less epics overall, and will reduce overhead entailed in feature launches.

Whatever you do, do not second guess yourself! NEVER reduce estimations and NEVER change the buffer just to be able to fit in more work. You are only lying to yourself, and will have to answer for this at the end of the next quarter.

At this point you may choose to stop, and move to document and communicate your plan to your managers, stakeholders and team. This might be an OK decision in case your team is relatively self-sufficient, and that team members have similar expertise. However, it is advisable to take the next and final step of planning your execution throughout the quarter. This will allow you to gain greater confidence in your commitments, and be able to better manage and track your plan (and inevitable changes to it) through the sprints. Whether you choose to stop here or not, do not forget to properly communicate your plan to all relevant stakeholders.

This tool is easily extendable to support multi-team planning.

Ready to try it out for yourself? -- Download a copy of the tool.

Asaf Bord Product Manager

Asaf Bord

Building a Quarterly Release Plan