A project should originate from users’ conversations and needs. It’s unlikely that a Pitch will be approved if no users have expressed interest or requested it.

Inspired by Request for Comments from Internet Engineering Task Force and Wikipedia's RPC process.

RFCs follow a lightweight, discussion-driven lifecycle:

Draft: The document is written but still evolving.

In Review: The proposal is open for comments, objections, and alternatives.

Accepted: Consensus is reached; the proposal is approved.

Implemented: The proposal has been executed and is now active.

Rejected: The proposal will not move forward (usually documented with reasons).

The key principles are: transparent stages, argumentation-first review, consensus-driven decisions, and implementation only after approval.

A Project is a larger, higher-uncertainty initiative that requires discovery, design, or cross-team planning.
An Enhancement is a small, well-scoped improvement to an existing feature, where both the problem and solution are clear and can be executed quickly.

Untitled Document

Untitled Document

Untitled Document

We use four levels of priority to triage issues:

Every issue should be labeled by type to improve clarity, ownership, and focus. Main types:

Task Type:

Scope:

Blocked by:

Browser:

Platfrom:

One of the beneficial consequences of the rise of Agile software development is the notion of splitting up large sets of requirements into smaller chunks. These chunks—stories—enable much more visibility into the progress of a development project. When a product is built story-by-story, with each story’s implementation fully integrated into the software product, everyone can see the product grow. By using stories that make sense to users, developers can steer the project by determining which stories to build next. This greater visibility helps encourage greater participation from users—no longer do they have to wait a year or more to see what the development team’s been up to.

But this chunking has some negative consequences. One of these is that it’s easy to lose the big picture of what a software system should do. You can end up with a jumble of pieces that don’t fit into a coherent whole. Or you can end up building a system that isn’t really helpful to the users, because you’ve missed the essence of what’s needed by getting lost in the details.

Story mapping is a technique that provides the big picture that a pile of stories so often misses.

That’s it, really—the description of this book in a single sentence. And that sentence carries with it the promise of a lot of value. A big picture helps communicate effectively with users, it helps everyone involved avoid building unnecessary features, and it provides an orientation for a coherent user experience. When I talk to my colleagues at ThoughtWorks about what they do to develop their stories, story mapping regularly comes up as a core technique. Often they’ve learned that technique from workshops run by Jeff, because he’s the one who developed the technique and can best communicate it. This book allows more people to understand this technique directly from its source.

But this isn’t just a book for people who have something like “business analyst” on their business card or online profile. Perhaps the biggest disausppointment for me in the decade of the adoption of Agile methods is the way that many programmers see stories as a one-way communication from analysts to them. Right from the beginning, stories were supposed to spark conversations. If you really want to come up with effective software to support an activity, then you need to look to those who build software as a vital source of ideas for its capabilities, because it’s programmers who know best what software can do. Programmers need to understand what their users are trying to achieve and should collaborate in building the stories that capture those users’ needs. A programmer who understands story mapping can better see the broader user context and can participate in framing the software—leading to a better job.

When Kent Beck (who originated the notion of a “story”) developed his ideas on software development, he called out communication as a key value of effective teams. Stories are the building blocks of communication between developers and those who use their work. Story maps organize and structure these building blocks, and thus enhance this communication process—which is the most critical part of software development itself.

In Mary Shelley’s famous science-fiction novel, Frankenstein, the mad Doctor Frankenstein builds a creature from disparate pieces of dead humans and brings the creature to life with the then-new technology of electricity. Of course, we know that this is not actually possible. You cannot create life by sewing together random body parts.

Yet this is what software developers attempt to do all the time. They add good features to software, one at a time, and then wonder why few users love their product. The heart of the conundrum is that developers are using their construction method as a design tool, but the two are not interchangeable.

It’s entirely reasonable that programmers build software one feature at a time. That’s a perfectly good strategy, proven over the years. What has also been proven over the years is that, when used as a method for designing the behavior and scope of a digital product, one-feature-at-a-time yields a Frankenstein monster of a program.

While they are intimately related, the practice of designing software behavior and the practice of building that software are distinctly different, and are typically performed by different people with different skill sets. The many hours that interaction designers spend observing users and mapping behavior patterns would drive most programmers batty. Conversely, the hours of sweating over algorithms are too solitary for most designers.

But when the two strains of practice—design and development—collaborate, the work becomes electric and has the potential to create a living, breathing product. Teamwork breathes life into the monster and makes people love it.

While the idea of collaboration is neither new nor particularly insightful, it is actually very difficult to do effectively. The way that developers work—their pace, language, and rhythm—is quite different from that of interaction designers.

Practitioners in each of the two fields are strong, capable, and internally well disciplined, yet they share a single, common weakness. It is really hard to express a design problem in programming terms, and it is equally hard to express a development problem in design terms. The two sister disciplines lack a common tongue. And that junction between the two disciplines is precisely where Jeff Patton lives.

Jeff’s method of story mapping makes sense to developers, and it makes equal sense to designers. Story mapping is the Rosetta Stone for our digital age.

Despite protestations to the contrary, Agile development is not a very useful design tool. It is a way of thinking about development that is design-friendly, which is a very good thing, but by itself it won’t get you to a product that users love. On the other hand, so many times we have seen good designs, well documented, given to developers—Agile or not—who manage to kill the essence of the design in the process of implementation.

Patton’s story mapping approach is the bridge over this chasm. Interaction design is all about finding the user’s truth and telling it as a narrative. Software development is all about breaking those narratives into tiny, functional chunks and implementing and integrating them. It’s so ridiculously easy for the essence of the narrative to slip away during this complex process. Yes, the functions are implemented, but the patient dies on the operating room table.

By mapping out the user’s stories, the design retains its narrative structure yet can still be deconstructed for effective implementation. The designer’s story, which is a formalized version of the user’s story, remains intact throughout the development.

The conventional corporate world has proven that it is nearly impossible for a team of two or three hundred people to build a product that people love. Meanwhile the startup community has proven that a team of four or five people can build small products that people love, but even these little products eventually grow big and lose their spark. The challenge we face is creating big software that people love. Big software serves large audiences doing complex, commercially viable jobs. It’s ridiculously hard to make such software fun to use and easy to learn.

The only way we are going to build big software that is not a Frankenstein monster is by learning how to integrate the disciplines of software design and development. Nobody knows how to do that better than Jeff Patton.

Building a map is dead simple. Working together with others, I’ll tell the story of a product, writing each big step the users take in the story on sticky notes in a left-to-right flow. Then, we’ll go back and talk about the details of each step, and write those details down on sticky notes and place them vertically under each step. The result is a simple grid-like structure that tells a story from left to right, and breaks it into details from top to bottom. It’s fun and fast. And those details make a better backlog of stories for our Agile development projects.

Building Shared Understanding

If we get together and talk you can te

Writing small titles in cards (stories) and discussing upon them was a great way of prioritizing, taking into account that one card could take hours or even days of development. User Story Mapping Book

The current state of the User Story Map is not what we are going to build. It is how we imagine Today the Product from the Future. However, having a clear path of the Future Product allows us to define better the software we are building today. Also, as we build today we keep on changing the future dynamically. The Future Product is in constant change: features are removed and added, their priority is changed and they get defined in detail. As we learn from Today we defined the User Stories of the future, hammering down the product. Once a User Story is well enough defined, and has gone through weeks surviving as a to be develop feature that will benefit our users, we will start developing it.

Inspired by Design Process and User Story Mapping: