Story Mapping for Agility, Part 1: Escaping Scrummerfall

Agile is what we are, Scrum is what we do.

Edited by Jay Quibodeaux

Be sure to read part 2, Story Mapping for Agility, Part 2: Making it Agile with Business Value

Intro

Many companies searching for improvements in predictability, quality, innovation, and speed implement Scrum and are disappointed by the results. This happens because what they see as a problem with execution is actually a problem with planning. They have appended Scrum to the existing Waterfall planning process with little or no gain, and therefore think that Agile has failed.

One Fortune 500 CTO even said to me, “I don’t care how you do it, just get it done.” Implying that for a given requirements document, you should get the same results whether you use Waterfall or Scrum. However, if you do, you are clearly not embracing the entirety of Agile, but rather devolving it to a project management technique for a “better” Waterfall that meets a projected schedule, often made without the team’s input. We just hand them a plan with fixed time, budget, and scope and expect it all to work out.

I would argue if any part of our process is Waterfall, it’s all Waterfall (also known as “Scrummerfall”). If Scrum is administered by professionals in Scrummerfall I have seen teams get maybe 15% increases in productivity, versus 75% when we plan and execute in an Agile way. This planning issue goes to the heart of many transformations. Every time a project under-performs, the well-meaning business people double down on the requirements, and the developers do their best to toe the line, becoming order takers instead of strategic partners. It’s a continuosly devolving spiral. Further, as the teams uncover the complexity of the solution, it is seen as “scope creep.” Hardly individuals over process or responding to change over the plan.

“Understanding that Agile is a philosophy that informs the entire value stream and not just a developmental methodology will help you avoid Scrummerfall and get much higher productivity."

It’s easy to understand how we got here. Humans have evolved to be very cause-and-effect oriented. To see how embedded this is in our thinking, look at magic. Magic is all about giving the illusion of cause-and-effect, and then giving us a surprise ending. It is a form of entertainment that has developed independently in all cultures over thousands of years, and yet not only do we never tire of it, our cause-and-effect expectations never get rewired, no matter how many times we get fooled. Even magicians get fooled by other magicians! (The entire premise of the Penn & Teller show Fool Us!)

Add to that that our enterprise culture is based on the success of the assembly line and other forms of meticulous planning and centralized oversight. This planning got us the Model T, the Golden Gate Bridge, the moon landing, and the 747. All very complicated and very successful projects. Such thinking has been further extended and refined in Lean for Manufacturing. Lots of things still benefit from this thinking. I would not want somebody to build me an Agile house, lest I spend 38 years to get a Winchester Mystery House(1).

However, meticulous plans fail in complex, non-linear domains, many of which are familiar to us. For instance, the 747 went from blank page to flying aircraft in 18 months. But the 737 Max was grounded for longer than that for a software problem.

We do have a lot of personal experience with complexity in daily life. Consider virtually any game or sport can be used as a metaphor to see that no matter how much we plan in the complex domain, the outcome is based on thousands of split-second decisions over the course of play. While the term “scrum” comes from rugby, I think football is a much better metaphor for Agility. You may have a plan going in, but have four-down sprints and use huddles to replan between every down. We would never say that a team won or lost a game based entirely on how well it was planned out in advance.

Or, consider the weather. Weather forecasting uses some of the most powerful computers in the world, and now has access to very granular data. So locally, you can get hourly forecasts that are very accurate. However, the seven-day forecast is still not all that correct. This is because small changes, such as rounding a few decimal places, can have large changes in the modeling. This even has a name: “The Butterfly Effect(2).” While there are many excellent reasons we wish the weather could be more accurately forecast over longer periods, it is simply impossible. No amount of computing power can help with these predictions.

In this way it is an excellent metaphor for Agile planning. We can only estimate things that are far away, but the estimates get much better the shorter they are. We’re pretty good at closing sprints, but that does not guarantee we can use Scrum to execute an exact plan.

This is why Agile came about: because assembly-line thinking fails for code and other creative efforts. No matter how much we deny or wish it was different, this is the case. No amount of planning can fix this. The goals of agility are the same as they are Lean for Manufacturing, but the means of obtaining those goals are not. Hence, the more correct terms “Lean-Agile,” or “Lean for Software.” If we really want to get different results, we must embrace this (relatively) new way of thinking from a project’s inception and not just in the delivery phase. Unfortunately, there has not been a lot of penetration of Agility in business or engineering curriculums, so we must find a way to teach this in the workplace.

Requirements Are Waste

While Scrum or other iterative frameworks are necessary to Agility, by themselves they are not sufficient. I would argue that Story Mapping, not Scrum, is the first step to Agility. That may seem a bit hyperbolic, so let me explain. Typical Waterfall requirements-gathering violates two of the Agile Manifesto statements outright (working software over documentation and customer collaboration over contract negotiation), and the other two as a result. We continue to focus on the process in an attempt to have a better plan, but in actuality we end up obviating the Manifesto. I would postulate that it’s rather difficult to get the benefits of Agility while ignoring the Manifesto from the start. For these reasons and many more, I’ll make another hyperbolic statement: Requirements documents are waste. I’m not alone in this. Jeff Patton, author of User Story Mapping(3), makes the same case in considerably more detail in his book.

As long as companies continue traditional requirements gathering, this will never change. This can never change, no matter how much time we spend doubling down on the things in the right column of the Manifesto. Why is this? Because if a team is trying to make stories from requirements documents, they are already doing it wrong. They are trying to build a solution rather than solve a problem.

"Agile is all about defining the problem space and collaborating to solve it. Waterfall is all about defining the solution space and hiring somebody to build it."

Most people have heard versions of the annual XP (eXtreme Programming) survey quote that “65-75% of features are rarely or never used.” This is because with specification-based contracts, we don’t know which of those features are even needed, so we are forced to create this waste, or we aren’t “done.” Rather than “maximizing the work undone,” this approach maximizes the work we do both in requirements gathering and in the amount of code we write. No wonder people feel their transformations are failing.

Integration

Waterfall spends a lot of time gathering requirements to build the “perfect “software. These documents look at every possible use case and generate enormous documents. They normally follow the functional layers of the code: architecture, data storage, APIs, UX. We call this “horizontal slicing.” The requirements get baked into the contract, and teams turn these horizontally sliced requirements into monolithic backlogs of technical stories, which then require integration. This takes away one of the primary advantages of Scrum, the production of integrated, “done” code every sprint. This is what “working software” in the Manifesto means.

Integration is buggy, takes time, and is expensive. I have worked at companies where the releases regularly contain 30% of the solution contracted for, and yet customers continue to pay for iterations until all their requirements are done. They wait years for a complete solution. At one company, one “on time” six-month release had 1100 bugs – including that the software could not be installed – 800 of which were generated in the “integration” phase of the release. But this is so typical that it hardly gets remarked on. There is a “that’s just the way it is” mentality. People have even said those exact words to me. The business beats up on dev for a sprint or two, and then everybody goes back to business as normal, delivering buggy, partial solutions. It’s an endless loop that nobody feels empowered to change.

“In Agile, working, fit-to-purpose code is the deliverable. In Waterfall the plan is the deliverable."

I believe this is where the “Is Agile Dead?” comments and posts come from. This is not Agility, and calling it such paints Agile in an unfair light. Agile is not dead, it’s just not well understood or implemented. In fact, it is very much alive, and the best companies are the ones who understand it best as explained in a recent (2/24) Forbes Magazine article “Why The World’s Most Valuable Firms Are So Agile(4).” And we need it now more than ever. That’s why even companies who have failed in transformations will eventually give them another try.

Time

Another aspect of waste is that requirements specification can take, literally, years. Sometimes they age out before they are even implemented. We don’t have that time any more. Now, markets can completely change in months. For example, look at the disruption from ChatGPT. I worked with one team that got a demo from an Azure architect who replicated their entire output for the past year in an hour by using AI/ML. If our teams are locked into building solutions and are not able to embrace disruptive technologies as they emerge, the competition will. We are setting ourselves up for disruption.

In another example of requirements aging out, I once worked with a team that had a backlog five years deep. Nobody on the team knew where these requirements came from, what problem they were solving, or if we still had the customer. Yet their job was to fulfill these requirements! The team ended up deleting anything that was more than a year old, and nobody ever came asking for those stories. This was a great example of self-management.

In contrast, a team I was working with was building a tool to determine greenhouse gas emissions (GHG) at refineries. It turns out refinery leaks are where half of all GHG emissions take place. To make sure they understood the problem, in their first sprint the team produced and demoed a tool to 20 customers. This was intended to be an eighteen-month project, but every single customer took the demo tool because it already had so much Business Value for them. That is what we want from Agility: to deliver working code as soon as it has enough business value, not when we are “done.” We can no longer afford eighteen months to start reducing greenhouse gasses or to address any other problem that has business value. Story mapping is a powerful way to drive this sense of urgency home.

Finally, any process you can move earlier in the pipeline or “shift left,” is going to be innately more Lean-Agile and have less waste. We want our teams to form a strategic partnership with the business and customers, before we write code.

Enter Story Mapping

In my experience, the simplest way to get teams on a path from Scrummerfall to Agility is to implement Story Mapping.

Jeff Patton restates the principle of “maximizing work undone” in a simple way:

“Our job is to minimize the code we write.”

For my money, that is the most important sentence in the whole book. Imagine if you could go to market in 25% of the time, with higher technical quality, more business value, actual innovation, and record customer satisfaction. Would you change your business process for that? I have seen these results in multiple engagements, all from story mapping as described here.

Outputs over Outcomes

I see this problem – the Business and Development teams starting out with differing expectations of done or what that project should be – all the time. How do we fix this? If we want the aforementioned benefits of Agility, we need to define our work in an Agile way. Wouldn’t it be preferable to make the best software we can in the time we have and measure “done” as an outcome of fit-to-purpose? Especially if it was faster, easier, had better customer satisfaction, and – dare I say it – was more fun? We do this by scrapping traditional output-based requirements and instead creating outcome-based requirements

This is the pivot that story mapping makes: From requirements that are monolithic, non-prioritized, all-or-none outputs that describe the system we are building; to outcomes, the things users can do with the system. Defining outcomes is a much better way to define the software and eliminates the creation of waste because by focusing on what happens outside the system (outcomes) to decide about what happens inside the system (outputs) we can control the scope of the project.

• Requirements are monolithic, non-prioritized, all-or-none outputs that describe the system we are building.
• But software is about outcomes: the things users can do with the system. Defining outcomes is a much better way to define the software and eliminates the creation of waste.

"It turns out, Story Mapping is also fast, lightweight, and cuts waste by up to 75%. It is hands down the easiest thing you can do to tactically improve your Agile maturity today, and it has deep strategic implications for metrics and contracts as your transformation matures."

I’ve used this method for the last decade to “back into” Agility in Scrummerfall environments.

Story Mapping Advantages

This is where story mapping comes in. Tactical benefits of story mapping:

• Switches from solution definition to problem definition (outputs to outcomes).
• Is fast. (Sometimes as little as half a day.)
• Requirements do not age out.
• Users, Business, and Dev all speak the same language.
• Supports continuous integration.
• Provides continuous business value delivery.
• Allows for innovation.
• Provides transparency.
• Uses collaborative user feedback.
• Eliminates waste by not gathering requirements we don’t need; and not writing, testing, documenting, and deploying code people won’t use.
• Reduces risk by focusing on fit-to-purpose software measured through customer satisfaction, not contracts.
• Builds on success.
• Focuses on closing sprints with demonstrable, integrated code.
• Enables continuous refinement.
• Is fun. People engage in a way they can’t with requirements docs. This improves team health, and this improves productivity by as much as 300%! (I have personally measured this.)

But in addition, story maps lay the ground work for numerous strategic benefits beyond those in Jeff’s book:

• Integrates with all Design Thinking methodologies.
• Allows true Agile metrics.
• Switches from features, which are subject to change, to Business Capabilities, which are stable.
• Lays the groundwork for measuring the Business Value of a project.
• Allows Agile Contracts.
• Can be used for Resource Planning. (You can make hierarchical story maps starting with your Strategic Roadmap.)
• Allows for lightweight scaling.
• Gives “better” estimations.

Story Mapping Goals

• Understand the context from the user’s perspective.
• Shared understanding with all stakeholders.
• Minimize the software we write.
• Create a high-level, feature-based backlog (outcomes).
• Estimate the backlog.
• Rough demo-based release plan.
• Drive UX discussions.

Story Mapping Process

This version of the story mapping process is as lightweight as possible, yet it still has phenomenal value. It is specifically designed on the tactical level for teams in a Scrummerfall environment. Once people see the benefit and you build the muscle, you can go deeper. In Part Two, I’ll address the strategic uses for more mature teams.

A story map is a “talkument” which captures the Agile plan in an information-rich table which can be used for ongoing discussion about the project.

1. Whom are we solving this for?
2. What is the problem worth solving?
3. What business capabilities do we need to add/improve to make this happen?
4. What would that look like?
5. What stories do we need to create these features? These are your columns.
6. Prioritize and estimate.
7. Iterate on estimates.
8. Slice into a release strategy based on demoing outcomes.

Who:

Ideally, we want the internal stakeholders, the people paying for the project, in the room, at least until we get to the backlog level of the map. We want the customer or somebody who can speak for the customer. We want the scrum teams. We want the Product Owners who can speak for the business.

When:

How long: Four hours to two weeks, with a preference for shorter.

Ideally, we would do this with the customer, before the contracts get written. Again, we want to talk to the customers about problems to solve and the outcomes they generate. Doesn’t this make more sense than spending months or even years creating a requirements document which has no bearing on quality?

But, if you already have a requirements doc and the contract is signed, you should still story map. On my last project, the Engineering Manager allowed the Agile coaches a week at the start of a new, requirements-driven release to story map. In that time, we made story maps for all thirteen of his teams, and held a big room planning to discover dependencies. Over the course of the six-month release, we quadrupled the teams’ productivity (400%) and cut the bug count technical debt by an order of magnitude (90%). Originally a skeptic, the leader said, “We will never not story map.” A year later, his teams went from six-month releases to releasing every month. The business still hasn’t changed how they contract, but the customers don’t care because they have fully functional code that does what they want in any given release. In this way, the code is eminently more predictable than the old, Waterfall plan.

Personas – Who is the user?

Ideally, we would have a user in the room to explain the pain points. If that's not possible, it’s not a showstopper. Often, we create a persona that encapsulates the user(s). Whichever way we get there, the point is to know or create a person the team can relate to. What is their gender, education, experience, goals? Write this down and keep it front and center for the team. I put it on the top row of the story map. We always discover a super important fact that requirement specs would never capture. For instance, in one story map I did, we discovered that the user’s bonus is based on how well our software works. The team had been working on this software for years and did not know that. Having this kind of information is key to software quality in terms of fit-to-purpose. It gave us a whole new lens through which we looked at stories.

I also coach teams to put the user/persona name into the user story template: “As Wendy, I want…” Some of the best discussions I’ve ever heard were when a developer would say “Well, George would never do that. That story makes no sense.” That clearly exhibits some deep empathy for the customer while also eliminating time spent creating features people won’t use.

• Spend some time getting to know the user: experience level, goals, frustrations, preferences, etc. Flesh her out, write her description, use her name in stories, put her picture on the wall. On one job, we put life-size cardboard cut outs of our personas in the scrum room.
• We will reuse our personas for multiple releases.
• If we have multiple personas, sometimes we create a “super user” which encompasses several roles, for example a supervisor may have a superset of a workers abilities, so if we make them our persona, both are covered. This can be very powerful. Microsoft Office was based on only 7 personas.
• Be sure to revisit personas over time to ensure that new insights are captured which will help to better represent them in future conversations.

Problem Worth Solving:

At the very least, you need to start with a problem worth solving. This is the second row of the map. This should be the raison d’être for making the software. It is astonishing how hard this can be to figure out, but it is also one of the biggest misses for many software teams. If you don’t know why you are building something, how can you be sure that the software is valuable? I’ve been on high-priority, fully funded projects that were cancelled because when asked “Why?”, the stakeholders could not answer. Imagine the waste if we had forged on. On another project where we asked “Why?”, we were able to replace 100 stories in the backlog with one lunch time of user training on the existing software. Do not skip this step.

This is why it’s so important to have the stakeholders in the room if you can. We want to change the definition of finished from one of time, budget, and scope, to one of fit-to-purpose measured by customer satisfaction and business value. The easiest way to have this conversation is if the internal and external customers are in the room. Often, I find that the business and the customer have completely different expectations. In one case, we were working the process for V3 of software. The dev team was saying that it was a complete waste of time. They knew everything. During a coffee break, I noticed that one woman hadn’t said anything so I walked over to her and asked what her role was and why she was there. She said, “I wrote the original tool in Access, and use it every day. Not one of these engineers has ever talked to me.” It turns out, she was an internal user and despite sitting less than 100 yards away, for 15 years, the dev team had never spoken to her. They only understood the external customer. When we reconvened, we introduced the new persona and the team was somewhat chagrinned.

Despite what people will tell you, most customers would rather be in the room, so ask them directly. I came onto a project that had been requirements gathering, with 50 to 100-person meetings, for two years. I wanted to story map with the customer, but was told repeatedly “That will never happen.” Finally I was told I could ask the customer directly. I went to the customer hat in hand and asked for two days to build a story map. The customer Product Owner said, “Are you kidding? We’ve been begging for something like this.” We got everything we needed in a day and a half and replaced the project spec with an eight-page Word doc with images of hand drawn workflows and the epics that would enable them.

Scenarios – The ideal future state

I personally use Scenarios to define the problem worth solving, because they are lightweight and come from the method I was trained in at Microsoft to solve the requirements problem, Scenario Focused Engineering(5). A scenario is not a use case, but it will cover about 80% of the use cases.

You can create them right on the spot, but they require some facilitation. Since a scenario is the ideal future state for your persona, I like to play the “Miracle Game” to get it: If our persona came to work tomorrow and all their problems were solved, how would they know? We are not trying to be exhaustive, but to cover ~80% of the features for a persona. The rest will come out in refinement.

A scenario is a narrative we capture in a couple of sentences to a couple of paragraphs, depending on the scope of the project. Do not constrain yourselves to just what we will create in this iteration. Think big. Thinking about the entire problem will help you plan for future iterations, promote innovation, and ensure your architecture scales with the solution.

Describe the ideal future state:

• What is hard that should be easy?
• What difficulties can we abstract them from through automation?
• How can we delight them? For instance, I just found out you can not only get your prescriptions from Amazon, but that they will sort the meds into pill packs for you. This is such a simple thing, but nobody has given this to the user before. This would’ve been a godsend when I was caretaking my parents and the pill sorting took up to 4 hours a month per parent. This fact alone sold me on having my prescription filled there.

If you have journey maps or other artifacts, you can start there, too. Just be careful that the design team does not run too far ahead of you and create elaborate documentation. Once you have put that much effort into a project, you can run into the fallacy of sunk costs, and you are back on track to a Waterfall project. For this reason, I prefer sketches done by the users and/or engineering team during story mapping to pixel-perfect UI images. Done early enough, story mapping should inform the UX, not the other way around.

Business Capabilities

After scenarios are discussed, there is one very important step. While it’s tempting to skip this step, I encourage you not to. This is defining which Business Capabilities we need to add or improve to reach the ideal future state. This is important for so many reasons. The first, tactical, reason is because business capabilities are stable whereas features are not. They define the technical problems to solve.

The second reason is that we want to build this muscle and make it part of the process. Strategically, as your practices mature, business capabilities will allow you to write Agile contracts and provide Agile metrics which are tied to your test plan and provide a new, Agile definition of when you are done. In this way, fully embracing story mapping can take you from rudimentary Agility to a fully mature Agile enterprise.

For example, we worked with a power company who had a compliance issue. To meet regulatory goals, they had to register 500,000 alternative energy devices (think solar panels) to the grid in one day. The customer had been gathering requirements for two years. But when we story mapped it, it was just four business capabilities: discover, model, register, and unregister the devices. The lead customer PO actually said, “I don’t care about the contract, as long as the software can do these four things by our due date.” If that’s not customer collaboration over contract negotiation, I don’t know what is.

We were able to tie the capabilities to the test plan so we could show progress. On the first iteration, we were able to discover the devices from aggregators. On the next, we could model the impact of a device on the grid. On the third, we could add a single device. Then we could add 30 devices. Then we could add 30 per minute. When we could add 1000 per minute, we knew we could hit the compliance target of 500,000 devices in a single day, which was the Business Value of the application. And, we did it with a month to spare. This led us to complete the next milestone of 1 million devices within the time we had. Originally this was thought to be out of scope and require a new contract. Needless to say, our customer satisfaction was through the roof.

The business capability conversation can be taxing and take some facilitation. But skipping it can lead to building the wrong thing entirely. In another example, I spent two days with a team doing a map for software that would replace existing manual manufacturing plant inspection forms. Because it was an existing application, we naively skipped the business capabilities step. What we ended up with was a backlog to replicate the paper forms in software, feature-by-feature. I challenged the team on this. Who used these forms and how? Who filled them out? Why did they fill them out? Where was the innovation? It turned out that the forms were filled out by people in PPE, including gloves, and then that information was digitized by seat-swiveling in the main office to compile a compliance report. I argued that the new design was going to make the form filler’s job harder – if not impossible – with PPE because they had to use a touch screen, and it would still require seat-swiveling in the office. In other words, the business value of the application was zero, and possibly negative. User delight was also zero.

We scrapped the first backlog entirely and settled on Reporting and Compliance as our business capabilities. Then we used native features of the hand-held devices (e.g., camera and voice activation) to capture the information much easier than before. To fulfill our Business Capabilities, we made sure the outcome from the phone was the final report that the back office was currently manually producing. By doing this, we ended up with a modern, innovative product that was miles ahead of what we originally mapped – an application that did not even solve the real problem and never had.

In the Greenhouse Gas example above, refineries have no easy way to find leaks. That was a business capability worth having because one half of all GHG emissions take place at the refinery. In other words, solving that one problem could solve half of the pollution caused by fossil fuels. It could literally save the planet.

“What would that look like?” Conversation

From the Business Capabilities, the next row in your map should be some sort of workflow. Try to write these as what outcomes are we looking for: logging in, sorting, reporting, communications, etc. They will map to the capabilities in a one-to-one or a one-to-few relationship.

There are many ways to get here. One technique is to have the user come up and start sketching screen shots. “From this screen, I need to make these decisions. From there, I need to go here….” My favorite technique is to break the attendees up into teams, give each team 30 minutes or so to propose a design, and then converge the designs to a best-of Paper Prototype(6).

You will not believe how excited people get when they are doing this. Everybody from the CEO to coders fresh out of college will participate, sketching and pitching ideas. This proves a truism my mentor once told me: “You are not doing a good job until somebody else grabs the marker.” The important point is that you are dealing with outcomes and not outputs, and you are creating a shared understanding through conversation. It’s okay to iterate on the outcomes at this level.

A fellow facilitator once asked me, “How do we streamline the conversations? I find them to be a bit messy.” Exactly. Revel in the messy conversations. That is the most important artifact of story mapping. For this reason, I like to come into the room knowing nothing about the problem or the product and ask all the stupid questions that everybody else assumes have been answered. Often, I discover that the different people in the room have completely different assumptions and my “stupid” questions were not so dumb after all. By coming in with no assumptions, you can check all assumptions. A facilitator can do this much better than somebody in the organization.

“It is a profitable thing, if one is wise, to seem foolish.” Aeschylus

Only once we understand the workflow as outcomes, do we go to the feature level of the map. To this point, the entire conversation should be technology agnostic.

Stories

Your screen shots sketches depict epics. At this point, we want to crowdsource story ideas. Do not edit this brainstorming session. (In the form example above, we actually considered Spot, the Boston Dynamic robot, to collect the data in dangerous environments. This really opened our thinking up. How does Spot collect data? Could we use some of those same technologies in our solution?)

For sure, many of the engineers will be proposing technical stories. Capture them without prejudice. Many stories will just be a single word, and often that’s all you need at this step. Once the brainstorming slows down, we can group the ideas into true user stories, and the technical stories become the Business Requirements to make those happen.

(ASIDE: I differentiate between outputs and outcomes when I write stories. Outcomes, things humans can do or things that happen from human interaction, become our Acceptance Criteria. The outputs, things machines do, to enable them are Business Rules.)

There is a fair bit of iteration here, but we can usually build a high-level backlog in 90 minutes or so. Please try to get everybody involved. Don’t let the technical or domain experts dominate the conversation. I sometimes like to have them just answer questions and not write any stories. Everybody should be putting stories on the board, either in person (preferable), or on a tool such as Miro if you are remote. But get everybody to participate, business, Scrum team, users, etc. Those new to the team are most likely to think outside the box.

For instance, the youngest members may have the most experience in ML/AI. In one story mapping, we worked hard and got the backlog in one day, planned for three releases over nine months. But the newest member of the team, fresh out of college, spoke up, “You know, if we used AI, we could go right to the final release and be done in three months.” He convinced the team, and we brought in the head engineer to get buy-in. Even if they didn’t make the new, aggressive schedule, they had six extra months to iterate on it and develop a new skill set.

Note something very important: We don’t scrap the idea of requirements, just how we get them. The business rules required by stories are the actual requirements, and we’ve eliminated waste by only capturing those requirements (outputs) we need to create an outcome. I like to use the Behavior-Driven Development format of Given-When-Then to record the business rules, which can then be used both in tasking and in acceptance testing.

A “nice-to-have” is a list of things you are not doing. It really helps define scope and set expectations. Again, we want to check all assumptions. If you put something on the not-doing list and the expectation is that it was in scope, now is the time to have the conversation.

Caveat: Once people get used to story mapping, they will try to do the work ahead of time and bring the team’s list of features, maybe even store them in a tool like Aha! But you lose the most important artifact of story mapping, the conversation. The team must be empowered to ask why they are building a feature and where it came from. It’s all too easy to say we are defining features and not specs and say we are Agile when in reality it’s just waterfall by another name. In 2023 alone, I did over 100 story maps, and the biggest time saver is to do them together in a truly collaborative manner. This will save no end of miscommunication.

Prioritization

If you’ve done it right, you have a map of vertically sliced work (containing stories that include thin slices of the entire application from UI to the database) that you can prioritize. I like to set a demo schedule to get out of time/budget/scope conversations and replace them with outcome conversations. In the first sprint, we plan to demo the following outcomes and provide the following business value. In the next sprint…etc.

Like any plan, this will not survive first contact with reality, but that’s okay. These are estimates, not promises. Again, you want the product and schedule to change based on feedback so that you can build the best possible software in the time you have. That is the Agile promise, not a specific feature set. Once you get the customer involved and they can see and play with the product as it evolves, they will be overjoyed with what you accomplish and far less concerned with what you don’t.

Estimation

We only map deep enough to get an Affinity Estimate and T-shirt sizing (in which stories are S, M, L, or XL). Affinity estimates are fast and easy and your Scrum Master or Coach should be able to facilitate them. You start by writing the sizes on the board: XS, S, M, L, XL. Then you find a story whose size the team can agree on and place it on the board in the appropriate column. Then pick another and simply ask “Is this bigger or smaller than the reference story?” and place it accordingly.

The estimate “lights up” areas of the map that need further elucidation. Generally, I try to break down any stories that are XL. Once we have no more XLs, we can calculate the backlog in points depending on your team’s correlations of T-shirt sizing to story points. Again, we don’t need to go too deep. Using crowd sourcing, it should take less than an hour to place all the stories in categories.

This is another place where great conversations happen, as people challenge or defend a particular story’s size. At this point, we don’t even have Acceptance Criteria, which will come in sprint refinement, and most of your stories will be epics. This is a first estimate. The only way to get a “better” estimate is to start working, not to do more planning. We will refine our estimate after every sprint. I have found a general rule of thumb is we can expect the first estimate to roughly double as the team better understands the problem. This is not scope creep; this is understanding growth.

Remember we are not trying to predict the future, but rather just get sufficient understanding to start. To maximize business value, planning needs to iterate based on feedback, not stick to the original plan at all costs. This is something we say, but rarely do. Remember the story map is a living document (“talkument”) and should be updated as we learn, for instance in refinement.

Walking Skeletons

One good way to start working is to build a Walking Skeleton(8), especially for new technology or big projects. Using what we learn from that, we can further tighten our estimates.

“A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function… It need not use the final architecture, but it should link together the main architectural components.”

Alistair Cockburn, signer of the Agie Manifesto

I was once working with a team that was co-branding a credit card with Chase Bank. Chase used REST and we used SOAP. At the end of story mapping, the team had bid had three full sprints for this integration. I challenged the team to do this in a week. The teams said "impossible." Then I challenged the team to do this in a day. The team said "Aren't you listening?" The Dev Lead said it was impossible, but took on the challenge and that night he got it working in the sandbox environment in 3 hours. We went from six weeks with 8 people to 3 hours with one person. This shows how conservatively teams bid risk and how important it is to remove it through experimentation. Seeing this, other teams started asking if they could do Walking Skeletons and their backlogs also benefited greatly from this practice. It may seem like you are slowing down, but in the end, removing risk speeds teams up enormously.

Scaling

For larger projects this would be a good time to go into big room planning and determine a dependency map. Using this map, we can determine if any scaling is necessary. I think of scaling as a question of integration. If we find multiple teams are working from the same map with dependencies, combining them and working out of the same backlog makes sense so that they integrate every sprint. If they are working from the same map without dependencies, we can give them their own backlogs.

In one case, to solve an immediate customer need, we had two teams from different groups whose work needed to be integrated after two sprints. Putting them into the same backlog was deemed “too expensive” and “too time-consuming.” So, for want of a 90-minute Agile planning session, they worked independently for two sprints and took three sprints to integrate the work, delivering this “hot” project a month-and-a-half late. It’s ironic that teams who have been managed in time-consuming Waterfall are not given the time to self-manage in Scrum. This really drove home that we never have too little time to plan or replan.

In Closing:

If you are in Scummerfall, be realistic about what you can and cannot achieve through Scrum alone and communicate that. Real change requires people understand that software cannot be handled through traditional project management. And, appending scrum to the existing business processes is insufficient. You need to make changes to your entire value stream. But if you get the chance, story mapping any project will give you a tremendous ROI. Perhaps even enough to continue on this Agile journey.

• Traditional requirements documents take too long, capture the wrong things, assure waste, and are anti-Agile.
• Story mapping puts the business, customers, and the scrum teams on the same page, looking at the same goals (maybe for the first time ever), in far less time.
• Story mapping is the most powerful if you have the customer, stakeholders, and scrum teams in the room and happens before contracting. (In fact, it allows Agile contracts, but that’s another blog.) But any version of story mapping is shifting left and more Agile than not. Take what you can get and build on it.
• Story maps are living documents. It may take a concentrated effort with skilled facilitation to get the first one, but eventually the map is iterated on in much smaller chunks during refinement.
• Even people who don’t “get” Agile learn to love story maps. I’ve never had a team who started using them stop using them.
• Story mapping gives “better” estimates because we are measuring things that matter and adjusting every sprint.
• As always, refer to the manifesto and principles to make sure that your new tool does not devolve into another flavor of Waterfall. Generally, if something is bothering you, go to root causes and address it through Agile fundamentals, not band aids.
• Most importantly, Story Maps lay the basis for true Agility. With them we can write outcome-based contracts which are based on Business Value metrics.
• Remember, this is a Primer, trying to give the simplest implementation possible. If it resonated, please read Jeff’s book to see how truly Agile teams use this tool, and stay tuned for Part 2, how they can be used strategically.

References

1)????? Winchester Mystery House: https://winchestermysteryhouse.com/

2)????? The Butterfly Effect: https://en.wikipedia.org/wiki/Butterfly_effect

3)????? User Story Mapping, Jeff Patton: https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909/ref=sr_1_1?keywords=user+story+mapping&sr=8-1https://www.amazon.com/User-Story-Mapping-Discover-Product/dp/1491904909/ref=sr_1_1?keywords=user+story+mapping&sr=8-1

4)????? Forbes article: https://www.forbes.com/sites/stevedenning/2024/02/26/why-the-worlds-most-valuable-firms-are-so-agile/?sh=26e78c41d794

5)????? Scenario Focused Engineering: https://www.microsoftpressstore.com/store/scenario-focused-engineering-a-toolbox-for-innovation-9780133967234

6)????? Paper Prototyping: Phttps://www.uxpin.com/studio/blog/paper-prototyping-the-practical-beginners-guide/

7)????? Boston Dynamics Spot: https://bostondynamics.com/products/spot/

8)????? Walking Skeletons: https://web.archive.org/web/20140329201356/https://alistair.cockburn.us/Walking+skeleton https://www.dhirubhai.net/posts/alistaircockburn_the-walking-skeleton-activity-7019708087791935490-4oOq/

?

?