Release planning (part 1): How to plan a new feature in 2 steps

Release planning: The process

Ever wondered how you will manage to forecast a release with a new feature? Do you only have a rough idea of what you need to deliver, but not exactly know where you should start? You were assigned a new team and don’t know the team’s velocity to help you plan?

No worries, here we’re going to cover the process to help you better with your release planning, from the initial problem hypothesis to the estimating and forecasting, covering 2 scenarios where the team is newly formed or when you’re planning a project that will start ahead into the future.

The process that follows is common for release planning a product in an Agile way:

• Having a rough idea of what to deliver, what value it brings, and for whom we deliver (covering the WHY part);
  • Defining the business need and what problem it tackles;
  • Understanding the personas targeted;
  • Defining the solution.
• Defining a story-map, an impact map, and deciding which testable hypothesis we want to test (covering the HOW part);
  • Create an impact map;
  • Creating a story map;
  • Defining the MVP;
  • Estimating and forecasting;
  • Roadmap planning. ( covered in part 2 )
• Delivering the MVP, gathering data, repeating, and improving the process ( covering the WHAT part ). ( will be covered in part 2 )

Defining the business need: covering the WHY part

In this step of the release planning, we will want to understand what is exactly the problem space or the business perimeter we’re trying to tackle. There might be different cases here involved:

• Did you found out about a new market opportunity or was it brought to your attention by other stakeholders?;
• Is it a new product or an existing product?.

But the common theme is that you will have a rough idea about why you’re doing this, the problem you’re trying to tackle and the customers targeted expressed as personas.

If you’ve followed a Design Thinking process, this roughly equates to the Empathize and Define stages, you can read a brief overview of the Design Thinking process here.

You can also start by creating a Lean Canvas as described in one of my posts here. What is important is to have the Problem, Customer segment clear, and a UVP ( what sets you apart ).

Notice that we haven’t focused on a solution so far. If it is a brand new product or a completely new problem you’re facing, then following the Design Thinking process here you will probably run a Design Sprint in the Ideate stage, to rapidly generate some ideas and user-tested facades. These will provide sufficient information for the next process and can jump straight into release planning.

If this is a familiar topic in your product domain, you might already know what to implement and the Personas to use.
I will also cover the Persona generation technique in a different post.

A template for this stage would be:

As a <USER persona> I want to use <solution> in order for me to <solve PROBLEM / end benefit >

The market in <industry> potential is <numbers>.
Currently we have: <number> contracts/market share/growth. ( this may be a bullet list, with different metrics )
By focusing on <USER persona> and solving <PROBLEM> we will expect to grow these by doing <specific actions> and getting <specific numbers>. ( again this may be a bullet list )

UVP: <What we’re selling> <for whom> <what’s in it for them>
E.g.: “Paperless insurances on the go. Log into your mobile device and use it anywhere. Cheap with no commitment.“

Having this in place you can now start with the next step into your release planning process.

Getting into specifics: the HOW part of the release planning

Impact mapping

If you noticed, we’ve started this phase with creating an Impact Map. Why is this useful? Because a good impact map will:

• Clear the business needs and goals for the teams;
• Align stakeholders;
• Find out something new or maybe something that was missed;
• Clear out metrics and what to track;
• Clear out personas;
• And most importantly, helps you by identifying common patterns ( for your epics/themes ) and deliverables for these patterns ( PBIs ).

I will cover impact mapping in a different post, because this is a whole topic on its own, for now I will cover the most important parts of the map:

• Goal: The goal is the business goal we’re trying to achieve. It is usually best that we keep the impact map focused on a singular specific goal that we’ve identified in the defining Business Need process;
• Actor: This is also the Persona. I have seen usage such as “Customers” or “IT Operations” and etc. But this should be customer-centric, by having the persona clearly and specifically defined. “Customers” or “IT Operations” clearly are too vague and do not bring any value. This is the same persona from the defining Business Need process;
• Impact: These are the activities the Actor needs to do in order to accomplish the Goal. It ties the Business Objective ( Goal ) with the Personas
  ( Actor ). These activities are reached by either using an Ideation process from Design Thinking or by brainstorming sessions with the team and stakeholders or by using similar functionalities that you’ve already developed ( existing experience, behavioral metrics from analytics,
  etc. );
• Deliverables: These are the actual requirements you will have to deliver in order to satisfy the Activities. In the end, these will be your PBIs
  ( Product Backlog Items ).

As you can see from the example above, we have been very specific about what our goal is ( increase by 20% conversion rate ) and who our users are ( doctors and patients, registered in our app, that use mobile devices ).

We can already start grouping the above activities into themes:

• Update availability and Book availability = Calendar epic;
• Post medical content = Blog epic;
• Pay for different services = Mobile Payment epic.

These epics can be also grouped by platform or any other functional domain, e.g. (iOS) Calendar, (Android) Blog, (ApplePAY) Mobile Payment, etc.

With the common themes in place, we’re ready to jump to our story map.

Story mapping

A story map is a two dimension representation of Personas, Themes, Activities and PBIs.

On one dimension ( X-horizontal axis) we will have Themes and User Activities grouped by Personas and on the other dimension ( Y-vertical
axis ) we will have the PBIs grouped by User Activities arranged top to bottom by priority ( top having the most priority and bottom the least priority ).

You can think of a story map as a more customer-centric backlog, focusing on the user experience and where each deliverable fit in the customer journey.

Going forward with our medical services app, here’s how a Story Map would look:

Defining the MVP

When doing the Story Map, always prioritize at least using a MoSCoW technique ( Must-Should-Could-Won’t do ), from top to bottom.
I prefer to use a hybrid model of MoSCoW and Kano models, I will write a later post to detail further the prioritization techniques.

The first release will be the MVP ( minimum viable product ).

We can see that the first release is the MVP, which will offer us feedback early on and it has the complete customer journey, BUT has some or no performance attributes and no exciters ( so only the MUSTs from the MoSCoW ).

As you can see, comparing an MVP with a car, an MVP is not only the wheels or only the driving wheel, it’s a complete usable car, but the most basic one.

That is why we’ve linked ourselves to an existing payment option in a web view, we will deliver as performance features ApplePay integration later on. If we didn’t have an already available payment option, then just prompting the users to wire transfer would have been enough.

Estimating and forecasting

Estimating and forecasting are a big part of your release planning process.
IMPORTANT NOTE: For all the below points, everything should be expressed as a range.

In release planning we have:

• The work to be done;
• A team that does the work;
• A budget for the two above;
• A timeline to deliver work.

Now there are also three dimensions that go into the release planning:

• Time;
• Scope;
• Budget.

Please remember, that one of the main decision criteria in choosing between an Agile approach and a Waterfall approach is knowledge of the requirements, in other words, the degree of uncertainty.

Agile frameworks are catered towards complex problems, meaning involving high risk and uncertainties.

Usually, there will be two aspects that will be uncertain at the beginning of the project, and those usually are Time and Scope.

Meaning we’re going to have to figure out how much we’re going to do and in our budget scope.

We have three ways to do this, and all of them involve using the team’s velocity ( meaning the pace of the team ):

1. Use historical values;
2. Run an iteration;
3. Make a forecast.

Run an iteration

Now, the first point is very relevant and for most of your career you will be going to use point 1, preferably you will be using point 2, with the least favorite being point 3.

Using historical values is pretty straightforward, gather the Velocity of the team for the past 10 (3 as a minimum) and do an average, so were going to focus on the other 2 points.

Probably you’ve recognized these from Mike Cohn’s “Agile Estimating and Planning” book ( if not, I urge you to read it ), so I’m going to speak from experience here: 1 iteration will not be enough, 3 will not be supported by the sponsors. So what can we do? Here’s how I’ve done it 🙂

1. Refine the subject before the project starts as much as you can;
2. Do magic estimations;
3. Involve stakeholders from business as much as you can, in each of your refinement sessions with the team.

So, before the project starts, if you do the above steps, the team will be aware of the subject and you, most importantly, will know exactly what will be the pain points. Trust me on this one, when the team quotes something above the 13 SP threshold, that will be a point you will need to gather more data on, break down into details and focus your refinement sessions on.

Ok, so let’s say you’ve refined the subject before the project starts and you’re wondering about magic estimations from above.

Magic estimations are all about speed and gathering feedback about what the potentially complex issues will be. I honestly prefer a hybrid model between Magic Estimations and Poker Planning.

Before the project starts, and after we have our kick-off, I present only the headlines of the stories, defined as specific and atomically as I can.

Where I cannot define the stories headlines as mentioned above, I ask for the team’s feedback and help, so that we might end up having more headlines than originally defined or less. After this quick collaboration exercise, I ask for the team to poker estimate each and every headline.

Having all these headlines defined and “magically estimated” top-of-the-head will give you something valuable: the potential blocking points.

Not having any values, how do you decide how many PBIs to select for the first iteration?
A nice technique is to assign 8 SP to each team member, if we have 5 team members, the possible velocity will be around 40. So you will select PBIs worth of maximum 40 SP. At the end of the Iteration, you will see exactly how much of those 40 have been actually done, it could be 30, it could be 20, but nonetheless, you will have a clearer view after this first iteration.

Now you’re ready to run your first iteration. During your first iteration, you’re going to continue refining and adding detail towards the rest of the MVP as part of your regular refinement process.

Having a 2-week sprint iteration into the project, meaning 1 month, usually isn’t such an over cost towards the whole project, but there will be cases when this will not be agreed upon or you’re planning way ahead in the future, so what shall we do next? Enter dreadful point 3 in your release planning process.

Make a forecast

1. Estimate the number of hours each team member will work on a project each day;
2. Find out total number of hours spent on the project during the iteration;
3. Split the PBIs into smaller tasks and estimate them in hours and choose the PBIs that fit into the number of hours in the iteration;
4. Use ranges.

Let’s go over each point individually:

1. Estimate the number of hours each team member will work on a project each day and total number spent on an iteration:
   First, you ask the team for known: trainings, holidays and anything that is not project related. Then, depending on the maturity of the team and your organization’s efficiency, you multiply the total hours spent by the team with a multiplier. The reason behind this is that usually, a team member does not work 100% on the project.
   
   So anywhere between 60-80%, meaning 0.6 or 0.8 will do. Let’s say you have a team of 5 developers that are full-time and you have a Sprint of two weeks, this roughly equates to 5*8 (full-time hours ) * (10 working days – Sprint ceremonies = 8 ) = 320 hours/Sprint.
   
   We’ve also mentioned the multiplier, so in our case, if the team is all on the same level of knowledge and involvement, we will multiply 320 * 0.8 = 256 hours. If the team is not on the same level of knowledge or has different project allocations, you will have to use a multiplier for each team member and then use the sum of all the hours resulted.
   
   Going forward with our crude example, have you noticed anything missing? Production incidents, if you have those, timebox 10% out of 256 hours/Sprint, that means you’re left with 254 hours for actual work. NOTE: this is an estimate, you will see more real values once you’re a few sprints into development.
   
2. Split PBIs into tasks and estimate each task with the team, in hours. NOTE: be careful at the team’s skillset. A tester might have to wait for development and a database engineer might not do actual development.
3. Pick as many PBIs that fit into the available 254 hours. If the sum of the chosen subset is 221 and another PBI would have increased the number beyond 254 hours, then stop, 221 is reasonable. Also, if the team feels they can commit on 221, then stop.
   
   In the end, you should have a list with PBIs estimated in Story Points and with sub-tasks in hours.
   
4. With the total number of Story Points, you multiply those by some multipliers (like 0.5 – 1.5) to give you a possible range. In our case, if we go with the 221 hours per Sprint, which after selection they total for about 30 SP, we will get 30*0.5 = 15 and 30*1.5 = 45, so a possible range of velocity sits in the range of 15-45 SP per Sprint.

With this in mind, in the end you will have a rough guideline of the Velocity. Take note that this will be gradually self-adjusted as you run iterations, so take them for what they are when starting planning, estimates.

Conclusion

Estimating and forecasting is just that, a forecast. In specialized literature, there is this concept of the Cone of Uncertainty, a concept borrowed from hurricane impact prediction. The closer you are towards delivery the higher the chance of a precise estimate, the further you are, the less precise the estimate is, and the more risk the project will have.

Using techniques such as impact mapping and story mapping will help you know how to choose an MVP and what value it brings to your users and business. Going forward from there, you’ve learned 3 scenarios you will face when making estimations and forecasting and we’ve focused on the ones where the team might be newly formed or the project is planned in the future.

Hope you’ve learned something new to help you in your release planning process and keep an eye out for my next part in release planning.

Useful Links

• Mike Cohn’s Agile Estimation and Planning
• Impact Mapping
• Product Plan on Story Mapping
• The Cone of Uncertainty
• Design Thinking in a nutshell