Shared Understanding - Stories behind a well written user story

Shared documets aren’t shared understanding.

As you might have seen, sometimes there is a difference between what writer wanted to say when compared to what reader understood. Even though the reader believes he has clear understanding, actully he has a very different understanding when compared to what writer intended to communicate.

If the reader and writter sit down to talk about the document, soon they will realize there is something wrong. Then they go on the discuss further and ensure they have shared understanding, Now the document mean the same thing to both of them. This is illustrated in the figure below.

Points to ponder

• Its important to remember that requirements are just another name for the ideas we have that would help people
• The word “requirements” has been used to kill productive conversations about why and what problem it solves! => The word requirements as actually been used to mean shut up.
• Your company can’t get what it wnats unless your customers and users get something they want
• Good story conversations are about who and why, not just what.
• There’s always more to build than we have time or resources to build - always
• So, minimize output maximize outcome and impact
• The truth is, if you build a fraction of what’s required you can still make people very happy

To Summarize

• Stop trying to write perfect document
• The real goal of using stories is shared understanding
• So, go ahead and write something, anything. Then translate the productive conversation into words and pictures to build shared understanding.
• What’s most important isn’t whats written down, it’s what we remember when we read it.
• Stories are shared understanding about discussions that solve problems of customers.
• Job is NOT to build more software faster, it’s to maximize the outcome and impact we get from what we choose to build.

These are notes taken from User Mapping Story book by Jeff Patton Peter