Roadmap Planning: “steering” with product map

Roadmap planning is indispensable part of Agile project management that represents second level of 5 levels of agile planning that any team should somehow cover. As a best practice suggests it needs to be done by product owner every ~2-6 months, depending on the intensity of development.

  This exercise makes sure that entire team understands direction, goals and vision of the product team, brings many benefits and speeds things up by creating shared clarity about future and maintains high focus on the “vector” PO gives.

Recently I’ve facilitated Roadmap planning session applying  two techniques: planning poker and story map. For those who want to get details of both techniques I would recommend  nice extract from Mike Cohn’s “Agile Estimating and Planning”: http://planningpoker.com/detail.html and this nice article at Jeff Pathon’s blog: http://www.agileproductdesign.com/blog/the_new_backlog.html.

It was both interesting and challenging, especially since we’ve never try this before. It was great success since resulted in having clear, estimated and planed Roadmap for product fist steps.

Goals:

  • To share product roadmap and vision;
  • To make challenges and risks visible and clear and address them early;
  • To make approximate measurement the minimum required scope of the release of the product;
  • To predict possible release date range / manage product scope in the way to hit deadline;

Background/Preconditions:

  • PO prepared items (user stories and/or themes) written on index cards (one per card);
  • Items were grouped according to the story map (by corresponding key product functional areas);
  • Key area titles were stick to the glass wall at our big conference room;
  • Horizontal line was drawn to separate the first release content over the wall;
  • Scrum team in one room for 2 days;

Process:

  • PO presented key functional areas of the product being built, briefly describing what each area covers;
  • PO started presenting item after item, sticking on the corresponding map column of the wall, given priority he had in mind.
  • Team estimated item presented with planning poker.
  • When estimations were too different we’ve allowed 1 or 2 rounds of re-evaluations. Well, we did not played exact poker, since we were interested in the approximate estimations, so we took averaged estimations  (i.e. majority raised 5USP, some guys 8USP, 6 or 7 is taken as an average, more feeling-based);
  • As soon as a column was complete discussion on required minimum scope of the release content started and PO moves some items below/above “scope line” (also considering estimations and best guessing for ROI).
  • Moving on and on to the next product column and item after item of a story map;

Outcome:

As result of 2 days workshop we’ve manage to:

  • Gain shared clarity about what needs to be done to get product LIVE;
  • Identify biggest project risks and “hairy topics” with poker estimations (those had usually high estimates, more than 20 USP, clearly);
  • Agree on next steps (to start with risky but must-to-have items first);
  • Noticed dependencies among items and moved them up/down in the way to decrease them;
  • Estimate roadmap and predict delivery dates range (we’ve ended up having kind of 500 USP);

Estimations/Approximation:

  • On the level of details where items represent Themes rather than a requirements or stories according to the cone of uncertainty estimations vary from 0.8 to 1.25x factor. On the requirement/story level they also vary from 0.85 to 1.15x. Considering this I took an average  ratio, given the fact that some items were story sized, others were bigger (nice article that illustrates correlation between estimation accuracy and uncertainty from Agile101: http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/).
  • This number together with average team/historical velocity gave an idea of the range required to get product out within agreed scope;


Takeaways
:

  • Roadmap planning is a valuable and must to have regularly exercise;
  • It is both interesting and motivating for team members;
  • PO gains a lot of important insides about product that allows to manage release scope and prioritization to minimize risks and get to live ASAP;
  • Teams are enabled to plan more than  just in time architecture since bigger picture of the product becomes visible;
  • It shall be done outside of a sprint to guarantee 100% clear mind and focus;

P.S.: * many thanks to my CPO, would be impossible without his preparation and buy-in.

Advertisements

, , ,

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: