Posts Tagged Product Management

Dynamic Story Board: KANBANizing story map

“Imagination is everything. It is the preview of life’s coming attractions”. Albert Einstein

An interesting thought came to me while thinking on how to bring in dynamics in story map to make it a tool that will help PO both in day-to-day work/tracking and overall release management.

Key benefits that will serve this are:

  • A full picture of upcoming product being built (within scopes of upcoming releases);
  • Transparency about features are being worked on now/coming soon;
  • Highlighting what features are READY and DONE;
To get the complete idea one needs to know the concept of story maps.
Combining this idea with KANBAN flow management framework makes a nice tool for PO:

Dynamic Story Board

So, let me explain what rows of it mean:
  • Done row indicates stories that correspond to the functional areas of the product and are accepted by product owner in sprint review meeting(s), having story definition of DONE met.
  • Areas row indicates key functional areas of the product as any story map has.
  • Wip row indicates work-in-progress, e.g. stories that are part of the running sprint (that team committed upon);
  • Ready row indicates stories that are ready to be presented to team according to definition of ready. PO moves stories in this row only if those compliant with INVEST rule;
  • Pipeline row indicates all the stuff that is planned for the future. As you can see some stories are non-READY here for whatever reasons (not yet completed, or even bigger items (epics) that are not yet prepared for sprint planning and thus cannot be taken by development team);

NOTE: pipeline row can be splitted itself into several rows to indicate scope planned for releases.

This simple board will serve as Kanban-style board turned by 90 degrees CCW. You can always add rows that indicate whatever states your PO team will find beneficial. Such a board can be easily used by PO daily in managing both day-to-day focus on getting READY for upcoming sprint, while keeping an eye on overall priorities and backlog.

Here’s real-live example implemented:

Dynamic StoryMap LIVE

Advertisements

, , , , ,

Leave a comment

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.

, , ,

Leave a comment