Expanded EPIC boards

What's the problem?

As scrum teams, we always look to the Product Owner as the fountain of all knowledge and requirements with respect to our supply of work. Yet, I've found that often the big ideas or concepts for projects are so light on detail that POs are desperately in need of a way to translate the high level idea into a backlog of stories to get the dev team up and running

We've all been part of projects where the BAs and POs lock themselves away for a few weeks with a high level understanding of a project and come back with a list of user stories for the dev team to work on. By the time the devs see the requirements, its hard to see the wood for the trees. We get bogged down in the
details, the stories are sliced poorly & are not delivering vertical slices of functionality. Often there's no wiggle room. Its all MMF. We cant cut anything out.

Additionally, defining an entire release worth of stories in advance which, ultimately, require change or may get dropped from scope, results in a waste of PO time and a delay in getting the dev team up and running. (Dan North touches on this release planning anti pattern in his blog post "The Perils of estimation" http://dannorth.net/2009/07/01/the-perils-of-estimation/)

So whats the solution?

Well, I've had great success recently using a variation of an "Epic board" as a tool for getting a project up and running. Developers, PO's and BA's collectively deconstruct EPICs into user stories that add value and are small enough to be used in a sprint. You don't need to write up the stories just yet, simply identifying valuable, vertical slices of functionality can be enough.

So Whats an EPIC board?

For those who are familiar with Epic boards as a concept, you may be used to the techniques outlined here: http://agile101.wordpress.com/category/programme-management/agile-epic-board/ , where EPIC boards are used as a programme management tool, tracking parallel deliveries across multiple teams.

To be honest, I think this technique is a bit too "project manager-ish", a throwback to the old "Gannt chart wallpaper" days.

So, why would I want to use an EPIC board?

Where Epic boards are most valuable, I find, is as a way of visualising the work in a project and also, as an acceptable way to discuss requirements at a very high level without the need for debate about whether or not the story is too big/ too small for a sprint. For kick off,  an EPIC should be a perfectly acceptable level of
granularity for a requirement

Benefits:

Representing your project as an EPIC board can provide a lot of immediate advantages by

1. helping you explore your project concept and discover what actually needs to happen in order to realise it
2. helping you visualize the work that needs to happen to achieve the project goals (piccie)
3. helping you get from "big concept" to "sprint level user stories" quickly. (This  helps you get your dev team up and running quickly)
4.  providing a framework to encourage scope management - facilitating meaningful prioritisation discussions
5. facilitating faster time to market by making "must have" functionality more visible & more obvious.
6. helping you de-risk project delivery by making "most important" features more visible & more obvious.

So, what's the process?

Identify project goal(s)
ask your PO "What is/are the goal(s) of this project" - write them on cards/ post them on your wall
(e.g. goal = sell flights online)

For each goal, ask the PO
What is the minimum we need to do to achieve this goal? & when do we know we have achieved this goal? - write them on cards/ post them on your wall

These will most probably be your 1st level of EPIC stories. Be ruthless, only identify the most important things you absolutely have to do to achieve the goal. (e.g. view available flights/ select flights/ enter payment details/ book flights/ view receipt)

Break it down - Expand your EPICS
Start breaking the Epics down into smaller chunks or "SUB-EPICS" - write them on cards/ post them on your wall
This step is the exploration step. You break down your high level requirements into something a bit more meaningful, you start to get at some of the detail that was previously uncovered.
e.g. for "view available flights" epic, you might identify the following sub-epics: filter available flights by airport, filter available flights by date, filter available flights by price, filter available flights by airline, filter available flights by special requirements (dietary, special needs etc)

We start to see there are a lot of different use cases or features hidden in the seemingly simple "View available flights" story

Depending on the size of your project and epics, you should find that at this stage you will already have identified some stories that are small enough to work on in a sprint. if not just keep on breaking a requirement down until you feel you have.

Prioritise
(I've used the MSCW technique, which has worked quite well in these exercises)

When you've broken the EPICS down, the expanded EPIC board serves as a great visualization tool. It becomes obvious when you see all requirements side by side, that there are some elements of the EPIC that we could "potentially" go live without (In Orange below). Finding flights by airport & date are probably critical, but in theory, filtering by airline, price or special requirements are all enhancements. Nice features that would give the user a better experience, but would not necessarily prevent them from finding a flight that they want.

Do the minimum
For the 1st iteration of your project, just do the minimum you have to do to book a flight. Take the risk out of your delivery.  (The purple and blues)

If you have time leftover you can add the extra features (the Oranges). Enhance the experience for the customer, provide bells & whistle but ensure you have done the highest priority work first!

There are lost of other things that could go into a project like this, e.g. show link to hotel booking, car booking, holiday insurance etc. You could capture these if you like, but make sure you aren't putting them on the critical path. If halfway through your project you haven't successfully booked a flight but you can cross sell holiday insurance its not going to give your PO any confidence that you are on track to achieve the goal of the project which is to enable flight booking online.

Focus on the main goal, then incrementally add other pieces of value later

TIPS:

- all groups should be represented in the EPIC boarding session (PO/BA, DEV, Test, Scrum master)
- Use a white board initially. This makes it easier to make changes when you are expanding your epics and identifying sub-epics or stories. Once you think you have your EPIC board in a fairly "expanded" state, put them on cards on the wall.
- Don't worry if some EPICS can't be broken down just yet. Early on in a project you will know more about some requirements than you do others. Accept this, but make sure you get the analysis done before the dev team is ready to work on the EPIC.
- treat the EPIC board as a living document. keep updating it when you get fresh information. just like your release plan.
- As soon as you have identified some sprint level user stories, take those away, write them up and get the team up and running. Once they are sprinting, you can focus on getting the other EPICS expanded! 10% sprint level user stories is fine if you have identified most of the EPICS.We don't need to know everything up front. We can drive out details along the way.