User Story Mapping, page 8
Really Minimize Your Experiments
If we recognize that our goal is to learn, then we can minimize what we build and focus on building only what we need to learn. If you’re doing this well, it means that what you build early may not be production ready. In fact, if it is, you’ve likely done too much.
Here’s an example: when I was a product owner for a company that built software for large, chain retailers, I knew my products needed to run on a big Oracle database on the backend. But the database guys were sometimes a pain for me to work with. They wanted to scrutinize every change I made. Sometimes simple changes would take a week or more. That slowed down my team and me too much. The database guys’ concerns made sense, since all the other applications depended on that database. Breaking it was really risky for everyone. But they had a well-oiled process for evaluating and making database changes — it just took a long time.
The riskiest part for me was making sure my product was right. So we built early versions of software using simple, in-memory databases. Of course, they wouldn’t scale, and we could never release our early versions to a large general audience. But our early minimum viable product experiments (we didn’t call them that then) allowed us to test ideas with a small subset of customers and still use real data. After several iterations with customers, and after we found a solution we believed would work, we’d then make the database changes and switch our application off the in-memory database. The database guys liked us too, because they knew that when we made changes, we were confident they were the right ones.
Let’s Recap
Gary used a map to get out of the flat-backlog trap and see the big picture of his product, and then to really start focusing on who it was for and what it should be.
The teams at Globo.com used a map to coordinate a big plan across multiple teams and slice out a subset of work they believed would be a viable solution.
Eric used a map to slice out less-than-viable releases into minimum viable product experiments that allowed him to iteratively find what would be viable.
There’s one last challenge that seems to plague software development, and that’s finishing on time. Suppose you’re confident that you have something that should be built. And suppose others are depending on it going live on a specific date. There’s a secret to finishing on time that’s been known by artists for centuries. In the next chapter, we’ll learn how to apply it to software.
[6] Marty first described what he means by product discovery in this 2007 essay. He later describes it in more detail in his book Inspired: How to Create Products Customers Love (SVPG Press).
Chapter 4. Plan to Finish on Time
This is Aaron and Mike. They work for a company called Workiva. Workiva makes a suite of products on a platform called Wdesk. It solves big problems for large companies, and it’s one of the biggest software-as-a-service companies you’ve likely never heard of.
Aaron and Mike look happy, don’t they? But that’s typical for people who’ve worked together to solve tough problems. Or could it be because the guy on the right has a beer in his hand? Nah, that’s not it. It’s that feeling from having solved a tough problem that’s making them happy. The beer is just a reward for solving the tough problem. If you don’t get beer, or an equivalent reward, for solving tough problems where you work, you should have a talk with someone about that.
Aaron and Mike have just completed several rounds of product discovery, and they’re confident they have something that should be built and go into production.
For them, discovery started with framing the feature idea they were working with to really understand who it was for and why they were building it. Then they talked directly to customers to validate their guesses about how they were working today and what the real problems were. After that, they built simple prototypes. For Aaron and Mike, they were able to build simple electronic prototypes in Axure and test them with customers remotely — first to see if they valued the solution, and then to be confident that it was usable. For the feature they were working on, they didn’t feel like they needed to prototype in working software to learn what they needed.
After multiple iterations with simple prototypes, they finally felt confident they had something worth building. That may sound like a lot of work, but they did it all in about three days. Their last step was to create a backlog and a plan for delivering the feature. That’s their plan in the picture. It’s a good plan. And that’s why they’re happy.
It’s important to note that this map isn’t about a whole product, it’s just about a feature they’re adding to an existing product. That’s why it’s smaller than Gary’s in Chapter 1, or that of the Globo.com teams. I’m telling you this because some people mistakenly believe they need to map their whole product to make a small change, and they use that as a reason not to map.
Map only what you need to support your conversation.
Tell It to the Team
To build this new feature, these two guys will need to build shared understanding with their team. Their team needs to be able to point out problems and possibilities for improvement, and to estimate how long it’s going to take. That’s what they built this final map for. They used it to tell the feature’s story — step by step, from the user’s perspective. Notice the printed screens injected into the map? They pointed at screens and highlighted details while walking through the map so those listening could better envision the solution. The people at Disney who walk through movies using a storyboard have nothing on these guys.
When team members asked why the screen behaves as it does, they had stories to tell about variations they’d tried, and how users behaved. When the team asked detailed questions about exactly what happens when data is entered, or information submitted, these guys had given it thought and could answer. Or, when they didn’t know, they discussed ideas with the team, and made notes on the prototypes or sticky notes in the model. They even added a couple of sticky notes for details they hadn’t thought of, but the team did. Aaron told me that the team spotted several technical dependencies that he and Mike would never have found.
The Secret to Good Estimation
Anyone who’s been in the software development game for any length of time knows that one of the biggest challenges is estimating how long development will actually take. I’m going to let you in on one of the best-kept secrets of good estimation:
The best estimates come from developers who really understand what they’re estimating.
There are lots of methods that promise to give more accurate estimates. I’m not going to cover any of those here. But I will tell you none of them work if the people building the software don’t have shared understanding with one another, and with those who envisioned it.
Building shared understanding shouldn’t be a well-kept secret about estimation. So you should go tell someone else right now.
Plan to Build Piece by Piece
The team at Workiva can’t really get away with building less at this point. They can’t do what Globo.com did in Chapter 2 and cut things away, because they’ve already validated that they need it all. When they were prototyping, they were able to cut away a lot and validate that their solution was still valuable to customers. But, when you look at their map, it’s cut into three slices.
“Why would they care?” you might ask. A third of what the customers want is sort of like delivering a third of a sports car. No one could drive it. But Mike is the product owner. He doesn’t get to walk away after he’s identified a good solution. His role changes now, and he’s a bit more like a director in a movie. He’s got to be there as every scene is shot. And he’s got to decide which scenes should be shot first, and which scenes get shot last. He knows that in the end the entire movie needs to come together and look like one coherent whole.
So Mike worked with his team to create a development plan. This is what they did: they sliced their map into three, crosscutting slices.
The first slice cuts all the way through the functionality. Once they build all those pieces, they can see the functionality working from end to end. It wouldn’t work in all the situations it needs to, and if they shipped to users this way, those users would howl. But Mike and his team will be able to see the software running end to end. They’ll be able to put real data in it to see how well it performs, and they could apply some automated testing tools to it to see how well it scales. They can learn a lot about the technical risks that might cause them trouble later on. They can be more confident going forward that they will be able to release on time. Or, at least they’ll spot the unforeseen challenges that would slow them down. I call this first slice a functional walking skeleton — a term I borrowed from Alistair Cockburn. I’ve heard others call this a “steel thread” or a “tracer bullet.”
They’ll layer on the second slice to build up the functionality — to get it closer to releasable. Along the way, they’re likely to learn some things they couldn’t predict. They may have overlooked some characteristics this feature should have — finer points that weren’t explored in the prototype. They may have found that the system just doesn’t perform the way they expected and some extra work will need to be done to get the speed they want out of it. These are the “predictably unpredictables” — a concept closely related to Donald Rumsfeld’s “unknown unknowns.” Don’t pretend they don’t exist. You know they do.
Finally, they’ll layer on the third slice to refine the feature, to make it as polished as it can be. They’ll also add in some of those unpredictable things.
Don’t Release Each Slice
Each of these slices isn’t a release to customers and users: it’s a milestone the team members will use to stop and take stock of where they are. From a user and customer perspective it’s incomplete, so save yourselves the embarrassment.
Mike and Aaron’s team estimated this feature to be about two months’ worth of work. Like Eric, they used two-week sprints, so it would take them four sprints. I guess they could have made four slices, one for each sprint, but they weren’t thinking of it that way. And you shouldn’t, either. Think of these slices as three different buckets with different learning goals for each. Decide which sprints or iterations they’ll go into when the time comes.
The Other Secret to Good Estimation
One thing that seems to be a secret, but really shouldn’t be, is that estimates are…estimated. Hit the Web and find any list of oxymorons. I’m confident you’ll find this term there: accurate estimate. If we knew exactly how long things would take, then we wouldn’t have called it an estimate, would we?
But if you build little bits of software, one thing you can be pretty sure of is how long they took to build. That’s called measurement, and that’s quite a bit more accurate.
Ok, so here’s the other secret: the more frequently you measure, the better you get at predicting. If you commute to work every day, I suspect you’re pretty good at predicting how long it’ll take. If I asked you how long it’d take to get to a different address in roughly the same area, I’ll bet you could predict how long commuting there would take within plus or minus about 10 minutes. That’s the way estimation works.
By slicing large things into small things, we get more opportunities to measure. Of course, there’s some subtlety to this, but as a general principle, you’ll get better predictions if you’ve got more examples of how long similar things have taken to build.
As a product owner, Mike is ultimately on the hook for getting this feature released on time. He’s a good product owner, so he helps everyone in his small team take some ownership of that goal too. He treats these early estimates as his delivery budget.
Manage Your Budget
Mike and Aaron worked together with developers they trust early on to get an initial time estimate. They treat it as a budget. And they actively manage it.
With every small piece the team builds, they can measure how long that piece took to build. They treat what they’ve built as spending against their budget. They may find that they’re halfway through their budgeted time, but only a third of the way through building the feature. Certainly they didn’t expect that, but now they’re aware and they can do something about it. They could borrow some budget from other features they’re working on. Or there may be small changes they could make to the feature that won’t substantially change the benefit users get. Or they could just face the music and see what they can do to change expectations with the people they’ve promised delivery to.
Depending on how bad it is, they may all need more beer.
When slicing out a development strategy, they’ll look to tackle the things that may blow their budget as early as possible. Those are the risky things. And it’s conversations with the whole team that help spot them.
Exposing Risk in the Story Map
Chris Shinkle, SEP
A large security company set out to build a mid-price-point, wireless, access control system for medium-size buildings (e.g., schools, doctors’ offices, retail, etc.). The company hired SEP to develop the firmware within the locks as well as the wireless ZigBee gateway with which they communicated.
The project was technically exciting, but had all the ingredients for failure, including skimpy budget, tight timeline, midstream leadership changes, untested technology, and tons of scope bloat.
Of course, things quickly began to unravel. The project team had missed several milestones. The client was unhappy and team morale was low. During a retrospective, the team discovered the biggest driver for missing dates was unplanned work, mostly due to uncertainties and realized risks. Something needed to change.
Like any group of smart engineers, the team tackled the problem head on. Their solution? Modify the story map.
At a high level, they increased the frequency and fidelity of their story map. By increasing the frequency of story mapping at each interim release, they suspected they would increase the likelihood of identifying more risks. By increasing the fidelity of the map to include “Risk Stories” (in addition to normal Activities, Tasks, and Details), they suspected they would be able to visualize, discuss, and better manage the risks.
The results were astounding.
The team knew that the width and depth of a typical story map gave a sense of the project size. They also knew the number of paths through the map was a good indicator of complexity. But, since uncertainty and risk weren’t previously reflected in the story map, the map didn’t depict the actual amount of work (including learning) to be done.
The new map, with Risk Stories, gave a better picture for the size and complexity of the road ahead. Project size and complexity were better represented, because they were composed of both the original known stories as well as the new “unknown stories” — the risks, or the knowledge the team needed to gain to confidently move ahead with the known stories.
As you’d expect, the story map became much more useful for planning. It now highlighted risks and uncertainties that would need time from the team. The ability to incorporate that time into planning made the team much more predictable and reliable.
Side benefits included a tangible way to measure and update stakeholders on learning. In conjunction with the traditional feature burn-down chart, the team included a risk burn-down chart. It was particularly helpful for the customer to see the risk burn-down data when the feature burn-down didn’t look great.
At the end of the day, the team learned that increasing the frequency of story map creation and adding new Risk Stories are powerful ways to make your maps better reflect reality.
What Would da Vinci Do?
I often ask myself that. OK, I don’t really. But maybe I should.
What Mike and Aaron have done is to follow a strategy used by artists to finish in time. It’s one I’ve used for years with software. And, when I first met my friends at Globo.com, I found it’s one they use, because as I mentioned before, if they’re late with cool, new interactive stuff for the Olympics, the Olympic committee won’t reschedule the Olympics. I’ll guess this strategy is one you even use routinely, without thinking.
Let me first explain what da Vinci doesn’t do. But, unfortunately, it’s too often what people building software do try to do.
Suppose you were da Vinci, and you wanted to create a painting and were working the way a naïve software team does.[7] You might start with what you believe is a clear vision of the painting in your mind. Then you break up the painting into its parts. Let’s say you had five days to paint this painting. Every day you’d paint more parts. At the end of day five, huzzah! — you’re done! What could be simpler?
Only, it doesn’t work like that — at least not for artists. This way of creating things assumes our vision is correct and accurate. It also assumes something about the skill of the creator and her ability to precisely define parts without seeing them in context. If you do this in software development, it’s called an incremental strategy. It’s the way a bricklayer might build a wall. And it works if each piece is as regularly sized and well defined as a brick.
