Story mapping & User story priorisation by ROI (Business Value)

Question

For now I use 2 agile practices : - Story mapping : to define Themes/Epics/Stories - Stories priorisation by the ROI ( Business Value / Effort )

But, can I use both ?

For now I do the following: 1. the storry mapping, then I have my backlog and a clear view on the work. 2. Then I assign Business Values and Effort to compute the ROI (Return Of Invest) for each story. 3. Then I try to sort the stories based on ROI, that way I got what is really important first...

So, the problem is that after the last steps, the stories are mixed and I have several "long" EPICS, with several EPICS in parallel.

So, here is an example, with 3 EPICS (A, B, C), once I have ordered all the stories by ROI, you see on the bottom the "visual result" of my roadmap. If I hide the "sotries", I lost the "Clean" vision of what will be done when, I have 3 very long bar ! So it is difficult to "understand" the planning.

How can I manage this to have a clear vision ? When I look at my "roadmap" all the EPICS are really long and so become useless. Should I split my EPICS, by putting together all the stories with the same priority ? (by example)

Answer 1

I have never been a fan of generating a priority order of epics as this ignores the fact that when the epics are broken down into stories the priorities are likely to change.

For example:

Epic A becomes Story X and Story Y

Epic B becomes Story J and Story K

If the priority order of the stories is X, J, Y, K then which epic is the highest priority?

My recommendation would be to only do the story mapping on stories and avoid epics or themes as much as possible.

I would attempt to do this in several phases:

• First phase - first stab at the story mapping, defining themes/epics/stories.
• Second phase - look at the story map and identify any epics or themes that look to be relatively high priority based on where they are in the map. Break these epics or themes down into stories.
• Third phase - calculate value and effort for the stories in the story map that look to be relatively high priority.
• Fourth phase - Look at the map and taking into account value and effort decide if you need to change it around so that higher priority stories get done sooner.
• Repeat any of the above phases if necessary until you are happy with the prioritisation and level of detail.

Answer 2

One line of thinking I adopted when I first learned about epics years ago is to treat them exactly like user stories, just one level up. Hence, a user story must be complete-able within one sprint, so an epic must be sized to finish within one release period (usually three months or less). Like sprints, those periods remain the same length once chosen, for the same reasons.** It is okay to have several stories in flight in one sprint, and thus several epics in one release period. Each are rank-ordered against the others as a way of short-cutting decisions in flight. That is, if you are running out of time to complete two stories that share resources (people, testbeds, etc.), you automatically go with the higher-ranked story. Epic ranking achieves the same purpose: When prioritizing stories that use the same resources, the higher epic wins.

If you accept this premise, an answer to your question is to to "chunk" epics into single releases using the same discipline you now use to chunk stories into single sprints. I have applied this approach at several companies without issue; in fact, one program achieved 90% predictability on completing epics within a release, much higher than I expected.

**This need not block continuous delivery. It is simply a planning mechanism, intended to help customers and stakeholders know what major features are likely (though not promised) to be delivered over a period with enough time for them to plan related activities.