Story mapping is a remarkably simple idea. Using a simple map, you can work with others to tell a product’s story and see the big picture form as you do. Then, you carve up that big picture to make good planning decisions. Underneath all that is the simple concept of Agile stories.
The idea of stories originated with a very smart guy by the name of Kent Beck. Kent was working with other people on software development in the late ’90s, and he noticed that one of the biggest problems in software development sprang from the traditional process approach of using documents to describe precisely what we want—that is, the requirements. By now you know the problem with that. Different people can read the same document and imagine different things. They can even “sign off” on the document believing they’re in agreement.
It’s later, when we get into the thick of developing software—or even later than that, after it’s delivered—that we realize we weren’t thinking of the same things. Lots of people call this lack of shared understanding “bad requirements.”
Let me vent a minute here. I have the pleasure of working with lots of teams. And we often start work together by talking about their biggest challenges. And, hands down, the one I hear most is “bad requirements.” And then everyone points at that document. The document writer ...