Epic Mapping. The missing jigsaw piece

Epic Mapping - The missing jigsaw piece

In my previous blog don’t throw the baby out with the bath water I talked about how a key focus for me in following agile practices is ensuring that the benefits of practices followed in waterfall style development techniques are not lost when replacing them with more agile equivalents.

I feel quite lucky as I once tried to implement agile practices in a corporate banking environment which I think has aided my experience in recognising when these benefits are not being realised. In that environment one of the areas that I had the most difficulty with was the medium term estimation processes. As with my previous environment, here, and in my opinion the industry in general I think the medium term estimation (and therefore ability to prioritise) is an area we could improve.

I believe this is due to most estimation practices recommended by others following agile practices generally focus on short term estimates (naturally). I personally think this is an area we were really strong on here using, story points and weekly velocity to aid us. I’m currently writing another blog on this area which I will publish soon

To try and improve the troublesome area we use what I now refer to as Epic Mapping. It is essentially Story Mapping but ‘rebranded’ to avoid confusion internally with the more standard practice of story mapping. Normally this is done with lower level stories.

Like Story Mapping we have cards which have the higher level features horizontally. We then add cards beneath it which are all of the Epics required to meet that higher level feature. For example, a feature (or stream of work) may be to deliver a public API of our preexisitng machine learning agent tooling. The epics required to meet that might include ‘challenge integrator for credentials’ or ‘allow for device gathering’. Normally the product owner and team lead will try and prepare what they think the epics are in advance (to save time), then in the session we open that discussion up to the whole team.

The session has three main goals/steps.

• Ensuring the whole team are clear and agreed on the vision for the features, which are debateable. This makes sure everyone is bought into the vision and hopefully motivated to deliver it.
  
• Giving the opportunity for the whole team to highlight the required aspects which are currently missing from the list (or challenge ones which are there)
  
• Providing mid level estimates. We use ‘perfect pair weeks’
  

By the end of this meeting, we have a large chunk of work we expect to complete flushed out and estimated. This is all on a board in our war room which anyone can go and visit for an update and being a physical board encourages discussions. This is a great resource for all involved.

• Developers can quickly see where we’re going and suggest changes etc as required
  
• The team lead can more easily report on progress, slippages and where estimations were inaccurate, while easily managing resource planning. Most importantly this is recognised as early as possible which is important for setting expectations
  
• The product owner/managers have more effective reporting coming into them but can also quickly and easily visualise the impact of changes to other work
  
• The rest of the business should be more aware of the timeframes for the medium term roadmap being delivered (or deviated from) and so can ensure their output is aligned. For example, people in client facing roles can set expectations accordingly
  

All of this is achieved without spending masses of time or reducing agility in anyway

This is longer than I’d like a blog post to be normally. I don’t apologise for this as I’m so passionate about this being a topic which can massively aid us and those who are little earlier on their agile journey.

I hope this helps. Feel free to comment, share and discuss

Chris Watkins