Release planning using the Agile Strategy Map

The situation

One of my teams provides the SDK for a range of hardware products, of which some are still in development. The hardware product development is working with milestones, at which certain new features of the product are available or changes to the hardware layout are made. The SDK is expected to support these features and layout changes with the release of the milestone. Although many features are known upfront, requirements do change in the course of the milestone completion. Example: The hardware layout has a flaw and needs to be changed.

The SDK does get a major version update (e.g. from 2.5.0 to 2.6.0) with a milestone release. The team was struggling to plan the releases. The scope of the features was unknown. Features that were not needed for the release were started to be built in, only to be stopped one sprint later, because a major feature request was forgotton until the last sprint before the milestone release. The team has 2 product owners, of which one is more of a consulting product owner, and at the moment one main stakeholder (apart from a lot more).

The approach

My approach was to use a hierarchical backlog to plan the contents of a release. There are quite some ways to achieve that, like User Story Maps, Impact Mapping or, my preferred approach in this case, the Agile Strategy Map. I helped the product owners and the one main stakeholder creating the Map using sticky notes of different sizes and colors. Our Agile Strategy Map consists of the following elements:

• Release goal (large sticky note): The goal of the release in one sentence
• Critical Success Factor (red sticky notes): A CSF is a feature/item/etc. that has to be done in order to reach the release goal
• Possible Success Factor (yellow sticky notes): A PSF is a nice-to-have. It does not have to be done in order to reach the release goal
• Necessary Condition (orange sticky note): A sub work-item of a PSF/CSF. In order to complete a PSF/CSF, every NC has to be completed.

Our first map draft looked like this:

The Agile Strategy Map at the start of the release planning

In order to create the map, we took the following steps in a series of sessions:

Collect contents for the release

Everyone writes down what they think and/or know has to be in the release

Weight contents using Business Value Poker

Similar to Planning Poker, everyone defines the business value of the contents defined. This will nicely show in a later step that business value does not automatically mean higher priority.

Define the release goal

Once the contents and the business values were clear, define the release goal. This is one sentence that describes what will be achieved with this release

Identify CSF and PSF

Once the release goal is clear, identity the critical items that have to be done in order to reach the release goal. Everything else will be a PSF.

Prioritize

Prioritize the PSFs and CSFs based on the available information likes Business Value, PSF, CSF, etc. We only used small sticky notes with the priorities on them combined with a discussion, but any other means of priorization such as dot-voting, "buy a feature" or else is fine aswell. This will show that high business value does not automatically mean high priority. On the picture above you can see that the item with the highest business value 3000 only had priority 5.

Identify the NCs

Identify all the requirements and work items a CSF or PSF has. You can group NCs below another NC.

The result

The Agile Strategy Map near the end of the release

Creating the Agile Strategy Map for release planning had several benefits. First off, since we put up the map on a whiteboard accessible for everyone, everyone including stakeholders could see what we were up to. In this case it actually lead to a stakeholder causing a priority shift, since she saw that an item that was a very important customer request only had priority 8. It also helped us to remove certain subparts (NCs) of a feature (CSF/PSF) we thought had to be in the release, the most common reason being that we didn't have enough time to complete all the NCs for a feature and they weren't crucial for the release anyhow (which we didn't know beforehand). Having a hierarchical backlog helped us to only remove certain parts of a feature easily instead of dropping the whole feature. Last but not least we could track throughput of PSFs, CSFs and NCs and because of that we were able to make pretty good predictions on how many items will fit in the next release (example: For the next release we only prioritized until 10, knowing that anything below most likely won't make it anyhow).

P.S. One side note: There is no rule how many user stories come out of a PSF/CSF or a NC. In our case we had PSFs that were only one user story and NCs that were 3 user stories.

Different estimation methods compared

A while ago, I conducted a workshop about agile estimation. In this workshop, I showed the participants three (of many) different ways of estimation: Planning Poker, Magic Estimation and the Team Estimation Game.


Planning Poker [Interaction level: high]
Probably the classic estimation method. The product owner reads a user story, the team estimates using the planning poker cards. If there are any differences in the estimation, the team starts a short discussion about everyones different opinion of the story at hand. If after about 3 estimation rounds there is still no consensus, the story is obviously not clear enough and everyone tries to gather new information until the next estimation session. Planning Poker usually uses story points, although I've already seen cards with animals on it (quite a nice idea actually). The estimation session ends when either all the stories are estimated or when time is up.
At the workshop I let the participants estimate what it takes to clean a kitchen. During estimation the team realized, that story #1 and #4 are too large and split them up to 2 and 3 stories.

Magic Estimation [Interaction level: low - medium]
Probably the second classic estimation method. Prepare a flipchart (or similar) where you draw an arrow going up (symbolizing the increased complexity) and write your references beside the arrow, be it user stories, T-Shirt size or whatever you feel most comfortable with. The product owner reads a user story, writes it on a post-it and puts the post-it on the flipchart. This procedure is repeated for about 5 stories. The team then gets 2 minutes to stand in front of the flipchart and silently move the post-its to where it thinks they belong. If during the 2 minutes you realize, that a story is wandering around a lot, you might want to talk about some details after the 2 minutes. This whole procedure is repeated until there are no stories left or the time is up. 
At the workshop the result looked like this:

Team Estimation Game [Interaction level: low]
An estimation method I found a while ago here (page is in german) and have used at the workshop myself for the first time. This method is quite similar to magic estimation. As with magic estimation you need a flipchart prepared. The product owner brings all the stories on index cards to the estimation and lays them, heads down, on a table. Someone from the team (whoever wants to go first), takes the first story card, reads it out aloud and then puts it on the flipchart where ever he/she thinks it belongs. Now the second one in the team pulling a card can either put it besides, above or below the first story read. From the third story on, every team member has 3 possibilities for his move:

• Read the next story card and put it on the flipchart
• Reassign a story already on the flipchart, also explaining why he does that
• Skip

When reassigning a story, you might also mark the story with a dot. The more dots a story gets, the more opinions about it differ and you should discuss it in detail. Like with the two other estimation methods, the team estimation game ends when there are no more stories left or when time is up.

At the workshop the result of the team estimation game looked similar to magic estimation:

Conclusion:
In my time as a developer I only used planning poker (apart from any workshops or similar I attended). After having conducted this workshop, I still prefer planning poker over magic estimation and team estimation, since the interaction with planning poker is way higher than with the other two (which is also the conclusion of the workshop participants). That doesn't render magic estimation and team estimation totally useless, there are still valid use cases for them. They are actually quite useful when you need a lot stories estimated in a short time, e.g. at the beginning of a project. Other than that my favorite remains planning poker.