user story, requirement, design

User story, no requirement needed

user story, jeff patton, requirements, gandalf

“Here! Page 3,894 of the requirements document, how did we miss it?
“… this foe is beyond any of you. RUN! ” – Gandalf the Grey

Good design meets end-user need. Bad design wastes time and money. The difference is not about requirements. Requirements are your great, grandparent’s design directive. Effective design is about empathy and to understand empathy you need to understand the user story requirement.

Before development, every project team needs to understand what to build. In project management requirements gathering provides that essential view of what the project delivers. Good requirements assumes what the build is what the end-user requires. This up-front effort to understand user need is shared across many professions:

Whether the user had to sit through a presentation, scour documentation, search software, or fumble through a webpage on their smart phone, bad design creates bad feelings.

A requirements document is not a quality design tool.

Comprehensive Documentation … You Shall Not Pass!

Better design solutions are not found in more comprehensive, upfront, requirement documentation. Gathering more data does not provide better solutions. Lean-Agile software development advocates rapid feedback and demands prototypes get into the user hands for their reaction and response. The goal of early release is to:

  • Build less,
  • Validate often,
  • Deliver value early, and
  • Learn fast

More documentation takes more time away from delivering a work solutions. In an Agile project, the User Story replaces exhaustive, front-end documentation to capture user requirements throughout the project life cycle. In the late 1990s, Kent Beck introduced the User Story in Extreme Programming (XP) development method.

Extreme Programming is successful because it stresses customer satisfaction. Instead of delivering everything you could possibly want on some date far in the future this [Agile] process delivers the software you need as you need it. Extreme Programming empowers your developers to confidently respond to changing customer requirements, even late in the life cycle. Extreme Programming

A User Story acts as a place-holder for a conversation to gain shared understanding As digestible requirements in a simple and clear description, every story supports an end-user task, in their environment, to meet their need. Bad design frustrates. A User Story is goal-oriented design that enables.

user story, mapping, agile, requirements, Jeff Patton,

Each view valid, each adds to the value – image from User Story Mapping

In simple language, between one to two sentences, a view of a story provides collective insight to the entire development team uniquely informed by the entire development solution. Each insight as valid to hear and articulate for the design solution.

Precious? It’s Been Called That Before

Over the project life cycle, User Stories are easier to move and prioritize then a typical requirements document. Simply an index card with details written on it with a pen. What you write is the key. There is no absolute sample, but there are good guides, here is one:

user story, index, card, sample

User Story card, not a template, but a suggestion

The key to user stories are how they are used, not how they get written and there are good samples and common mistakes:

Stop trying to write the perfect document. Go ahead and write something, anything. Then use productive conversations with words and pictures to build shared understanding. The real goal of using stories is shared understanding. – Jeff Patton, User Story Mapping*

The brilliance of a user story lies in simplicity. If there is no definable linkage to a goal or user activity then ask “why?”. User stories focus on functionality and end-user value as money spent on the wrong development only succeeds to spend money.

A User Story is simple to reference and remains convenient to a host of design possibility.

A User Story focuses all product development effort meet end-user value. Where 100-page requirement documents arrive as an artifact, User Story cards become conversations.

Move from a requirement tome that you file away and move towards a User Story narrative that welcomes change to remain relevant to the end user, your market, and your financial health.

Further User Story Sources:

user story mapping, agile, design, book, Jeff Patton

Subscribe to Email Posts and Join 710 New Friends
I believe in your privacy and will never sell or spam your email.

Share this Post

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.