Blog

Story Mapping 201: Mid-project Story Mapping Made Less Painful

By: Reese Schmit | Sep 20, 2017 |  Agile Tools,  Article

If you read David’s blog about story mapping, you may have gotten extremely excited to try it out﹘and then the fear and doubt set in. Maybe you are smack in the middle of a project, and the thought of starting the planning section over, or worse throwing away all of your hard work, seems extremely wasteful and frustrating. You keep circling back to the visibility and flow story mapping shows and wishing you could benefit.

Well, folks, I’ve got good news. Just because you are in the middle of building something doesn’t mean story mapping isn’t for you. I’m not gonna lie. It’s gonna be a bit of work, but it will be well worth it.

Building the Map

Start where you are

The first step is to collect all the user stories you already have. If you are using a physical board, promise me you won’t steal the team’s cards away from them. Rather, transcribe the few they are in the middle of working on to new cards. If you are in JIRA, VSTS/TFS or another tool, print out all of your tickets. Yes, even the closed ones (this will make sense when we get to the “Fill in the Gaps” portion).

printed stack of user stories for your story map

 

Next, organize them into piles that make sense to you so you can easily find individual stories. Digging through 150 stories to find the one you are looking for will likely frustrate the crud out of you.

Now, a word of caution: User Stories tend to be nouns/features, whereas you want your story map to be verbs/actions/steps, so just starting from your existing backlog can create some friction. We are, instead, going to start with a simple journey map.

Map the Journey

This will be the backbone of your Story Map. It may be easier to think of this as a very high level, simple journey rather than going as in-depth as you might initially with the Story Map. You want to get the flow out, without worrying about the details yet.

mapping out the simple user journey before diving into the story map

Grab a pad of sticky notes (Pro tip: Super Sticky Post-Its™ are the best for vertical surfaces), a Sharpie, some painter’s tape, and claim a large wall. Just like building a Story Map from scratch, you want to start at the beginning. Ask yourself: How does the user flow through your product? Where do they start? It is usually easiest to start with the main persona’s journey, so write each step of their journey on a separate sticky.

Pull in Existing Tickets

As you come across those steps that already have a User Story, tape that up instead of writing a new note. This may be the majority of the steps. If that’s the case, awesome!!

The beginnings of a Story Map, a mix of your printed user stories and sticky notes full of the steps in a user journey your user stories may have missed

Your map will look something like the one above. The white cards represent the printed User Stories from your system of record or physical Product Backlog. The colored squares represent the new stickies.

[If you want to learn more about how to use Agile techniques to build better products, check out our guide to great Agile transformations, 8 Common Pitfalls of an Agile Transformation.]

Filling in the Gaps

You will likely find you have holes in your Story Map when it’s presented like this. You may also realize you were missing some pretty important activities, steps, or details that would have snuck up later in the project or right before release to bite you.

Here’s where the magic happens: The biggest issue we tend to have with our giant 150 ticket backlog is that not everything is truly vertically sliced nor are they sized correctly. When we take those 150 stories and place them where they belong in the steps of the user’s journey, we find the places that we should roll things up. Things we thought were independent are really creating dependencies. We find tiny little stories when we could deliver one large chunk easily inside of a sprint that is fully valuable and a complete thought.Fill in the gaps: add in important activities, steps, or details that the user stories left out

Once you have everything out there, find the themes. These are called “Activities”. They are the big, well, activities a user will accomplish that may have numerous steps within them. Large things like “manage email” or “upgrade” fall into this category.

Determining your “Release”

Yes, release is in quotes. This is because we are decoupling planning with release. Release is just the shorthand I’m using for a planning increment. You can think of these as Marketing releases or milestones. They don’t have to be done in a physical release. You may be doing continuous delivery which will mean things are “released” just not turned on. Or you may be releasing small increments, and testing them out but not doing a big bang announcement of the whole featureset. It doesn’t matter how you do it, just do what works best for you and your team.

 

First, you need to make sure the details under your steps are in priority order: must-haves at the top, nice to haves at the bottom. Then, take a roll of blue tape and wind your way through the details until you have determined what will be in your first “release”.Prioritize your story map by dividing the must-haves from the would-be-nice-to-haves with a line of tape

If winding through like the above example impedes clarity, you can create a tape line and move the cards that don’t belong in the first release below it, like so:An alternate method for prioritizing your story map (straight line as opposed to winding line)

Bringing Clarity to the Chaos

Organization is extremely important to being able to read the map. You don’t want just a wall of words﹘that looks chaotic. You want to be able to tell a very simple story while demonstrating that you can dig into the details when important.

Epics vs. Stories vs. Tasks

So are the “activities” on the top row considered epics, the “steps” the stories, and below that the tasks? Or is that top row something else and the steps are epics and the options stories? The short answer is that it doesn’t matter: do what’s right for your teams and the products you are working on. If the steps are things that can be completed inside of a sprint, they are probably more at the story level. If they are huge, two to three sprint things, they are likely epics. Again, the best bet is to take it to the team.2 options for breaking down your story map

Color Coding for Personas

You may want to color code if you are building for different user segments or different personas. For example, if you are building for mobile, web, and call-in users, different color stickies will create visibility into those segments like in the example below. Adding colored dots to the printed tickets will continue the visual color coding. It is helpful to put up a legend at the side so anyone can see what the colors mean at-a-glance.color coding your story map by user personas

Keeping it Alive

As with most things of this nature, if you just attend to it once, it’s outdated as soon as you walk away. A story map should be kept updated and be a living document throughout the project. When you find new steps or details, put them up there, update your priorities, and show progress. A great way to show progress is by simply indicating the ones that are done by drawing check mark on them in a bold color.check of completed task, activities, steps, etc. on your story map

 

So there you go. In a few straightforward steps, you’ve taken your unruly backlog and created a living asset that your team and stakeholders can use to easily see the bigger picture﹘all mid-project! This should help you and your team get on the path to creating a better product and building the right things no matter where you are in the development process.  

If you missed Story Mapping 101, just click here to go back and read that as well! 

 

If you want to learn more about how to use Agile techniques to build better products, check out our guide to great Agile transformations, 8 Common Pitfalls of an Agile Transformation.

We also cover story mapping in-depth during our Certified Scrum Product Owner class. Check it out.

Blog

Why Not DIY Agile

By: Reese Schmit | Jul 27, 2017 |  Agile Coaching,  Agile Transformation,  Article

The amazing thing about the human spirit is that we think we can do anything we set our mind to. The problem is that we don’t always follow up with, “but should we?” Let me tell you a tale of our deck.

Last spring my husband and I set a deadline to redo the deck that leads out to our back yard and subsequently our pool. The deadline: our baby becoming mobile. You see, a deck with unfettered access to a pool is not safe for a tiny human. Unfortunately, the deck we had led right into the pool without barrier, so my husband got to work.

He ordered a few books on deck building from Amazon, read them cover-to-cover, drew up plans in Google Sketch-up, and bam, we were ready to go. We put a project plan together, “hired” a few friends to come help us, and during one insanely hot June week, we built a deck. Sorta.

(more…)

Blog

Stop Wasting $$$ Building So Much Crap!

By: Reese Schmit | Jun 13, 2017 |  Article,  Product Owner

Building horse shoes is one thing... but horses don't need people shoes. Know what your user wants. Stop wasting money on useless junk.So many teams have a list of projects laid out on a roadmap sometimes months or years out, without a clear idea of how success is measured. Are they being measured based on the number of projects completed? Getting them done “on time”? High quality? Team utilization? Are any of these things helping meet the company objectives?

When did we stop experimenting and start believing we were always right?

Why are we spending so much money building things that may or may not have any real value? How are we even determining what we build?

We have spent years calling ourselves Lean or Agile, as we optimize the delivery of the highest priority items in our backlogs. That is making the big assumption that we’re building the right things. What we are probably doing, though, is building the wrong things, faster.

(more…)

Blog

How To Improve Cross-Functional Collaboration

By: Reese Schmit | May 31, 2017 |  Article,  Team

Cross-functional team collaboration means all kinds of people coming togetherCross-functional teams are at the heart of Agile development. What is a cross-functional team? It’s generally defined as a group of experts in their individual functional areas working towards a common goal. Most of the “teams” I’ve come across fit this definition. We have everyone needed to deliver the product increment from end-to-end, so what’s the problem?

While we may have all the people, if they can’t all do the work and are unable to collaborate, we end up just creating a mini waterfall of handoffs inside the sprint between silos and specialties. Collaboration is at the heart of a truly agile team. So how do we tip the scales towards collaboration?

(more…)

Blog

Agile System Coaching: The Whole Is Greater Than The Sum Of Its Parts

By: Reese Schmit | Mar 23, 2017 |  Agile Coaching,  Agile Transformation,  Article

A great Agile system runs as smoothly as the gears of a clockAristotle once made the observation the “whole is greater than the sum of its parts.” While mathematically this is untrue (the whole is equal), there is a sense of awe when watching independent parts work together towards one goal. Take the clock: When you look at the clock,  you see the moving hands denoting the passage of time. Lift the face and you see the many gears coupled together to make the hands move.  

As a Team Coach is driving individual teams towards empowerment and Agility, an organization will need to start optimizing beyond the team level, looking at how the products and structures within which the teams operate, interact. When organizations reach this point, the need for a System Coach arises.

This is the third post of our Agile Coaching series. Catch up on post one (Agile Team Coaches) and two (Agile Coaching Roles).

(more…)

Blog

Sustainable Pace For Everyone (Including Agilists)

By: Reese Schmit | Dec 12, 2016 |  Article,  Scrum

Nod your head if you have said the following:

  • “I need a day off so I can get some work done.”
  • “I’ve been in meetings for the last 6 hours solid.”
  • “It feels like I haven’t been at my desk in two days.”
  • “I’ll get to that this weekend.”

You’ve likely heard phrases like this around the office or said them yourself too many times. According to a Families and Work Institute study, one in three American employees is chronically overworked. Multitasking, interruptions, too many meetings, and an overwhelming workload are cited as some of the main contributors to their inability to maintain a reasonable work week.  As Agilists we drive home the concepts of focus, prioritization and sustainable pace for our teams but the rest of the company is left out to dry, including ourselves.

(more…)

Blog

ScrumMaster ≠ Manager

By: Reese Schmit | Nov 09, 2016 |  Article,  ScrumMaster,  Team

Vince Lombardi picture and quote about great coaches--much like the ScrumMaster role

The ScrumMaster role on the team is never static and takes on many forms. Their role is one of servant leadership; as the team needs, the ScrumMaster provides. When the team first adopts Scrum, the ScrumMaster plays the teacher: training the team on the mechanics of Scrum, guiding the Product Owner on how to build a backlog, educating stakeholders on the new ways they will be given transparency into the progress of the product.

As the team progresses the ScrumMaster transitions into more of a coach: creating space for the team to self-improve, mentoring Product Owners on increasing outcomes while reducing output, and helping stakeholders embrace team empowerment. In just the span of a day, the ScrumMaster will oscillate from teacher to coach to mentor to mom to confidante to guru to barista and back again 30 times.

There is one role, though, the ScrumMaster should never slide into for the team, and that is the manager. (more…)