“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:
- In communications, start with know your audience;
- In product management, starts with know your market;
- In software development, start with user requirements; and
- Is digital marketing, start with know your persona
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.
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 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:
- Definition of Ready,
- User Story INVEST criteria, and
- Definition of Done
- * User Story Mapping by Jeff Patton and Peter Economy
Share this Post
