Using story maps to retain the bigger picture once we have abandoned Big Design Up Front
Once we accept that Big Design Up Front doesn’t work, and that big version-controlled documents that can’t be easily revised and corrected don’t promote shared understanding in a team, then we’re ready to do Agile. Our team is excited and ready to experience this brave new world, freed from the burden of having to follow heavyweight processes that don’t add value.
But at this point, there is a huge trap waiting for inexperienced teams that haven’t done Agile before. It’s called the “Flat Backlog Trap”, and it comes about like this:
Everyone gets in a room together, and we’re all just sooooo excited. We have bad memories of Big Design Up Front that tried to detail the entire picture to the nth degree before we started anything – we know that is bad, we bear the scars. We’re so looking forward to just delivering for our stakeholders for a change, without all that burdensome nonsense.
We start to discuss Epics and User Stories, and we then ask how we should organise them.
“Oh that’s easy”, says Inexperienced Scrum Master. “Just put them in ruthless priority order in one big flat list, take an informed guess as to how much we can do in the upcoming sprint, detail those stories out, and forget about the rest for now. Doing any more would be wasteful, as we’re not developing it yet and don’t even know if it will be needed.”
This is an alluring trap, created through an entirely understandable desire to simplify, which is what Agile is supposed to do, right? Thinking stuff through is hard, and people get tired quickly when they do it. We know that thinking in too much detail too soon is fruitless, given that our learning in the project will inform our understanding of the remaining work and inevitably change it. So when someone says “oh don’t think through all that stuff that’s coming later, there’s no point”, we’re very happy to accept, and slope off back to our desks in relief. We’d rather be coding anyway and just concentrating on the next thing, right?
We LOVE flat lists!
There is some truth in what our Scrum Master friend is saying – there is no point thinking to too much depth about what is coming later. However, we need to ensure that we’re retaining an understanding of the breadth of the whole project, and crucially ensure that we drive out and understand the business goals and processes of what we’re building in a way that can be easily retained in our minds.
When we encourage people to only think in terms of the top 10 stories in the backlog, they lose this context, and then we run a huge risk of building items that do not fit with the items that come later in the backlog. Team motivation also suffers as people struggle to understand why they are doing something, and therefore don’t know if what they are doing makes sense in the wider context – this deprives them of the ability to feed back about the validity of the overall solution.
This is a criticism that BAs will often level at Agile projects – you lose the bigger picture, and so you still end up building the wrong thing. If this is happening, the Agile project is not being done right – processes are being applied too simplistically and we are not promoting shared understanding within the team, which can only lead to trouble. The fact that your backlog tool such as JIRA can show you everything in a tree organised by epics really doesn’t help – it just doesn’t convey the business process or sequence in which key activities are done.
So Big Documents don’t work, and a flat backlog doesn’t work, so what does?
We’ve found Story Mapping the most compelling way to drive out the overall business process that we are delivering, and to retain knowledge of where we are in that map as we progress through the prioritised backlog. In truth it’s been around a long time – it provides a simple and effective way to visualise the process that we are delivering, and then break it down in to the User Stories we all know and love, and then also to drive slices out of that picture that can give us our iterative releases.
Depending on your project setup, you may be able to use a wall to host your story map, or you may prefer to use one of the online tools that have sprung up recently to facilitate it. The image below is from the excellent Stories on Board tool:
(other tools are available 🙂 )
Here, we see major business goals on the top line. Beneath that, individual user activities that deliver the business goal. Ideally, we should also be listing the user types above the business goals, so that we can see who does what in this process.
We arrange the goals and activities horizontally, in a timeline from left to right. Many processes are not strictly linear, but this is a pragmatic approximation that is easy to visualise. Below each user activity, we list user stories, individual actions they will perform to deliver the overall activity. We list these in priority order, so vertical shows priority, while horizontal shows timeline.
What usually happens at this point is that we see we have far too much to build! This format then makes it easy to create several horizontal swimlanes representing releases, and to move individual stories between them. The result is an easily visualised map of our entire process and what we need to do to build it, which allows the entire team to keep a track of the bigger picture, whilst also working on their prioritised items from the backlog.
We’ve found that when using this format, participants are far more able to spot gaps or assumptions in the process, and are easily able to feed back to each other to collaboratively refine and correct the map. The technique is so simple that it often doesn’t need a facilitator after the first hour or so – you go and get a coffee, and the participants have done it themselves!