Visualizing Progress with Agile Storymapping

Visualizing Progress with Agile Storymapping

Kanban walls, status reports, risk logs … with so many project management tools, it's easy to fall into the complacent feeling that a project is staying on track. But keeping a project on-track in terms of enhanced user experience goes beyond just hitting that next release deadline: it’s also about adding value to the business and building features that matter to end users. It’s also important not forget the UX debt we may have built up thanks to shoddy software practices.

When it comes to keeping all of these elements in perspective, storymapping is a great technique that can help us focus on the bigger picture, while also keeping our wider stakeholder group (like developers and product owners) aware of the project’s progress. As designers, we are uniquely poised to maximize the potential of storymaps to help visualize the status of our team’s work and bring in a new flavor of project management to the development kitchen.

Let’s examine what storymaps are and then look at how to build one.

What are Storymaps?

Patton has gone on to write about how storymapping and UX relate, championing storymapping as way to alleviate the lack of common understanding that comes with trying to tie agile and UX together. As he explains, “[S]oftware has a backbone and a skeleton—and your map shows it.”

Agile Alliance defines storymapping rather formally as “a more structured approach to release planning … consisting of ordering user stories along two independent dimensions.” At its most basic though, storymaps are large card arrangements, not too dissimilar to other walls used in software development. The only difference with storymaps is that instead of focusing on the day-to-day "flow" of a team's development pace, a storymap reveals how tasks relate to larger buckets of work, grouped by activity.

In short, a storymap provides a visual representation of the overall piece of work you're trying to accomplish at a glance, rather than trying to keep it held up in documents. The photo below shows a story map in practice.

Storymaps are a great addition to any team’s project wall, whether next to in-use Kanban lanes or to-be design mockups. They help to flesh out what an entire project looks and feels like, illustrating how far your team has moved forward without trying to assign everything an ambiguous column.

And the best part about storymaps? You don’t have to use them strictly in agile environments. They work with all sort of activities and tasks. In fact, I’ve used storymaps to track everything from content strategy work to the requirements refresh of a banking system. They’re adaptable to a project’s needs and a team’s desires.

How Do Storymaps Help Projects?

Storymaps help with the planning, prioritizing, and visualizing of project work. Agile coach Steve Rogalsky explains that storymaps not only encourage iterative development (which is a key to evolving the design of a user experience), but also help with outward progress tracking—an added benefit for most visually oriented designers.

It’s often hard to track how big a project is and where we’re adding value. Storymapping takes a different approach to project management, looking at the entire project as a whole, using groupings to break the work up in manageable chunks.

Storymapping is not too far off from release mapping, but instead of thinking about our work in terms of batch releases, we think about it in terms of activities. As we begin each unit of work then, we can strike a line through it, X-ing entire tasks out once only they’re complete. This allows team members and stakeholders alike to see how far the project has moved. Most importantly, it helps people outside the project ask key questions about what’s holding the team back, providing insight and transparency into our work without formalizing the process.

How Do You Build One?

The creation of a storymap depends largely on what type of work you'd like to map out.

Start by breaking down your larger project into tasks (e.g. user stories or simple “to do” items) and translate them onto cards. Each task should be easy enough to accomplish within a reasonable amount of time (I try to keep tasks to a maximum of two weeks).

As Andrea Gigante reminds us, storymaps are very much alive, so we shouldn’t try and plan tasks that might take us into the ensuing years. Keeping them capped at about two weeks helps keep us honest with ourselves, and our stakeholders.

Next, sort your tasks into categories. There are two ways to do this: an open card sort or a closed card sort. Card sorts here would be essentially grouping your units of tasks into logical “activities” based on similar properties.

An open card sort allows you to figure out how things fall together randomly, while a closed card will help you align activities to business terminology. I prefer to use open card sorts as it allows me to define the grammar that shapes the project I’m working on. Designer Mike Long noted in his blog post on activity maps that mapping is great in this way, helping teams “create a precise and elegant lexicon that will sharpen [our] understanding about what [we] are trying accomplish.”

Lastly, organize your cards onto a wall in a clean and visible format. Jeff Patton and Steve Rogalsky put tasks under activities vertically, while others prefer to use a horizontal format.

I'm fond of the horizontal variety because you never know how big a story map will get. I tend to keep up all old tasks for an entire project, as it shows just how big a piece of work is actually becoming.

There's also an opportunity to add personal touches: I've had colleagues who insist on using sickies as a visual key to track cross-functional requirements, while others swear by using different color cards so that we don’t get confused by which tasks are assigned to which activity.

Again, the styles for building a storymap are endless. Improvise and adapt the technique to your own benefit.

A Word to the Wise

While storymaps are a fantastic technique to focus on outcomes over outputs, they're only successful if a wider stakeholder group has adopted them. I've had experiences trying to implement storymaps where I made the mistake of not including key team members in the creation process. Without this buy-in and participation from across different parts of the organization, the storymap was a useless artifact.

Bottom Line

Storymaps are only one tool to track the bigger picture as a team. When all is said and done, you should find a technique and style that suits your team best. As Laura Busche shared in her recent Smashing Mag article, any sort of working wall is "an invaluable tool for design thinking.”

ABOUT THE AUTHOR(S)

David Peter Simon is a consultant and blogger based in London. He works at ThoughtWorks, a global design and engineering firm, where select clients have included Amnesty International, GUCCI, UNICEF, Standard Bank, and the UK government. In his free time, he blogs for Indie Shuffle and Holiday Matinee. Talk with him on Twitter @davidpetersimon.

Add new comment

Login via:

Your name *

E-mail *

The content of this field is kept private and will not be shown publicly.

Comment *

Because of problems with spam comments, HTML in comments is not permitted. URLs are allowed, but they will not be rendered as click-able links.

The tool I'm involved with developing that supports this stuff is called Cardboard at www.cardboardit.com. The support for multiple people working from multiple locations is strong. I know some other folks who really like mural.ly.

One thing I'll always remind people is that the value of a map isn't in the model itself. It's in the shared understanding groups get by building them collaboratively. You can't beat the face to face for that. Close seconds are google-docs style collaborative tools.

There's lots better models to really use to communicate details to people outside the room. Journey Maps are great. And I love Todd Zaki-Warfel's Task Analysis Grid: http://www.servicedesigntools.org/tools/137 For me, I separate the idea of the work we do to make sense of things and design from the work we do to communicate our decisions. Story mapping - and working with sticky notes or cards on a tabletop will kick the a** of any tool out there for getting people on the same page fast. :-)

I had a good experience with cardboardit last week. We had a large story mapping session with one team in the room and two other teams attending remotely. The remote teams collaborated in breakout sessions on parts of the story map using cardboardit, then we came back together as a large group and shared learnings and stories from the breakout session, putting them up on a map on the wall, simultaneously scribing it onto a shared meeting session with cardboardit. The remote folks - on the phone for two full days - reported finding the meeting very engaging.

We didn't use the collaboration features of cardboardit - we didn't want the business users having to deal with a new tool - we just had one person using cardboardit sharing on webex. That might be for our next meeting.

ThoughtWorks makes a product called Mingle, which allows you to organize stories into maps. Check it out here: http://www.thoughtworks.com/products/mingle-agile-project-management/features-benefits#

Alternatively, Atlassian, a company dedicated to making collaboration tools, has a plug-in for Jira & Greenhopper which allows you to create storymaps. Just found a great article (similar to this one actually) detailing how to make a storymap using their plug-in. Read about it here: http://blogs.atlassian.com/2013/06/visualize-your-roadmap/

There's also Story Mapper by Carbon Five for Pivotal Tracker: https://storymapper.io/

You can also try FeatureMap at http://www.featuremap.co, a collaborative story mapping tool which allow you to visualize the high level progress.
Visualizing progress can work only if you create prioritized layers of features per sprint of your story map, to keep the flexibility of the approach.

Story Maps are wonderful tools. But I don't think they work well to "track progress". The benefit of story maps is to get an entire team, with management, to think about managing scope effectively. The conversations shifts from "is this whole project on track?" (fixed scope) to "what scope can we cut for our first release to manage product and business risk? (flexible scope)"

Heads-up: UXMatters is publishing a series by Lis Hubert and Donna Lichaw discussing storymapping for content strategy http://www.uxmatters.com/mt/archives/2014/02/storymapping-a-macgyver-approach-to-content-strategy-part-1.php

Hi David. If you're interested in learning more about the narrative storymapping we used (which has more to do with TV writing than agile, but looks the same on a wall :), I just taught a workshop on it and posted the slides: http://www.slideshare.net/dlichaw/storymapping-the-user-experience