This post is the last part of our series on making an Agile Roadmap.
You can find the two first parts here :
– The first one explained “why” we use Agile roadmaps
– The second one gave a detailed method on “how” to do it.
Let’s now talk about what it gives us and how we can use it!
Be prepared, it gets pretty interesting from here.
Third : Let’s Project
The goal of the wall-planning is to allow us to model ‘path-ways’ in our roadmap : the different possibilities we have regarding the path our product may take. As when making a map, we have to link the different dot together.
When the wall-planning exercise is finished (see our post on that exercise here), we do apply a simple process :
- – we use the sizing exercise to calculate the mean velocity of each sprint in fantasy “t-shirt / animal” units (remember, we defined them using those relative values to the team’s sprint total capacity)
- – we remove 20% to it : this is our margin for unknown events, vacation and holidays, you can put more but I would advise not to remove more than 30% unless it’s the only way for you to take environment instability into account
N.B. : Why don’t we use our sprint velocity? It’s all about making sure that the roadmaping exercise uses different symbols and value systems, in order to avoid dangerous approximations and translations. We want to explore possibilities, not look for commitment.
With that done, for each epic / story, we can place it in our product delivery timeline relatively to each other. For example, in each quaterly cycle.
To help you with that part, you will find here the simulator that we use internal at Seedbox to calculate roadmaps from wall-planning :
To use it, simply fill up the green parts with your own datas, as follow :
First tab : “Team parameters”
- In B2, the number of developers / team members that work on the product you wall-planned
- In C2, the number of developers / team members that WOULD work on the product you wall-planned in a first scenario (it can be more than B2 or less, it’s your choice :))
- In D2, the number of developers / team members that WOULD work on the product you wall-planned in a second scenario
- From B3 to B7, the link between our wall-planning scale and our team’s sprint capacity (in our example file : the whole team make 2 Small story each sprint)
- In B8, the margin for unknown and other event that you want to use
- In B10, the quarter with which you want to start
Second tab : “Wall-planning – Simulation”
- In the A column, ID’s if you need them as reference
- In the B column, a short description of the epic / story
- In the C column, the estimate given during the wall-planning for this epic / story
Result – “Wall-planning – Simulation”
You then get on the right of the second tab the probable delivery quarter for each epic / story :
- – in the H column, with your current team
- – in the I column, with the team for the first scenario
- – in the J column, with the team for the second scenario
you just made an Agile Product Roadmap.
Communicate, communicate, communicate
So what’s next ?
Painting is all well and good, but unless you want to wait until you are auctioned at Sotheby’s (so probably dead), as a successful painter / roadmapper, you HAVE to publicize your vision.
Both to your teams, and if you can, at large too.
Make it visual.
Make it pretty.
Make it sexy.
Make people want to get it as their desktop background, print it on a t-shirt…
Go as crazy as you think is needed, but make it visible!
Don’t sleep on it!
Now that you made an Agile Roadmap, I’ve got a bad news for you: you WILL NOT follow it. At least not to the letter.
And that’s OK !
Remember, the goal of the exercise is to give a rough estimate of the direction you want to take together with your teams, but as with painting, you must let creativity, exploration and mistake alter the course of your drawing. Inspect and adapt to the reality of what is now appearing.
You don’t want to be a copycat, you want to be artist!
Because you know that you will not always follow your roadmap strictly, take the time, each period (quarter seems like a good one) to enter a new Roadmaping exercise, to analyze and learn from what happened with the previous one.
You will probably learn that you were not so bad at understanding your market and you can even do better this time!
What you’ll get too, is the perfect occasion to sum-up all the period’s successes and challenges, and try to find a way to improve on that.
And THAT is all about being Agile.