In the first post of this series, I explained why visualisations can be so useful to keep teams on top of their immediate goals and longer-term objectives.

I recommend reading that post before this one. You have? Then let’s start simple, with a look at story maps.

Successful products evolve iteratively, allowing for learning after each iteration. They’re guided by a dynamic, ever-changing product backlog (a form of story map we’re pretty much all familiar with). For some teams (especially small teams, or those responsible for a single product), a decent product backlog is sometimes all that’s required.

Our team captured the ways we wanted the product to evolve within the backlog. These new features, operability improvements, etc. were driven by feedback; once in our backlog we’d ensure they were prioritised, communicated, and used to drive the product forward.

Why a product backlog is so useful

Our product backlog ensured that we were always delivering what was most important. It clarified the vision for the future of the product inline with the direction of the business – and how short term goals fed into the bigger picture.

It enabled the delivery team to focus on delivering stories, and it enabled the product owner and sponsor to be confident that the product’s direction was aligned to the overall business objectives. It also provided the entire team with a central place to consider and discuss the product, at whichever level of abstraction was required.

To unlock these benefits, we visualised the backlog with a story tree, which gave a holistic view of the team’s endeavours:

This story tree simply related our lower level delivery stories to their higher level business goals.

The tree was formed and maintained during collective story mapping sessions. These focused top down to clarify measurable objectives, deliverables, and measures of success. And we would avoid working on anything that wasn’t aligned to a higher level business goal.

Stories were still prioritised in a flat structure, which ensured no delivery constraints were introduced from higher up the tree. This allowed multiple business goals to progress in parallel as their stories and epics were delivered.

Roadmaps

Sometimes – especially as domain complexity increases or when a team becomes responsible for multiple products – other views of focus and direction can help.

Complexity was certainly a consideration on the engagement I’m using as an example. As well as facing significantly different contexts (receiving apps from other teams, delivering features, ensuring/improving service operability, etc), the apps our distributed team took ownership of were coupled to a business domain where key events occur predictably at certain points each year.

These key business events meant we could expect to see increased periods of product change and use at specific points in time. To help the team focus and pivot when needed, a roadmap became essential:

We kept our roadmap simple – it was certainly no Gantt chart (and we had to ensure the business understood that!). Onto it, we mapped known key dates, a (very) high level view of how much work might be needed to support the events in question, and a stab at which team might be best suited to do the work (based on domain knowledge and capacity).

As with everything we were doing, this was an evolving approach, created to solve a specific problem. No approach was set in stone – we went with whatever worked to support delivery assurance, increased throughput and a sense of ease within the team.

These roadmaps provided a simple, effective view that helped us recognise when to shift contexts in a manageable, non-destructive manner. Potential bottlenecks, risks, dependencies and growth requirements became apparent and we were able to take the steps needed to mitigate them. The more we learned, the more we iterated our view and our approach.

Even simpler views of focus

My experience is that developers enjoy, well, developing! And testers, testing. Which is as you’d expect – but we still needed to make sure we had a team culture where everyone recognised the value and need for other, less immediately gratifying activities.

It was a challenge to build the culture we wanted while simultaneously helping our client through a delivery transformation programme – visualisations helped greatly.

We ran whole-team workshops that expressed the vision and goals for the team. Simple slides and cards on a wall gave greater visibility to our different areas of focus (the same goals captured in our roadmaps and story trees).

We also added epic swimlanes to our agile boards, which helped the team keep one eye on the bigger picture.

If there’s a theme – it’s that visualisations can be very simple, but don’t underestimate just how useful they can be.

In the next part of this series, I’ll be looking at how we visualised blockers.

Part 1 – The power of visualisation
Part 2 – visualising stories (you’re here!)
Part 3 – visualising blockers
Part 4 – visualising risks