In agile environments you reduce big upfront design, because you know that customer requirements will change. Capturing requirements as User Stories is the most common approach. User stories are short and easy to use. They serve as reminders to have a conversation about the requirement.
Jeff Patton, the father of Story Mapping says, they are called stories, because we’re meant to have a conversation – tell a story – about them.
PS: A good User Stories is INVEST
Are you a budding Product Owner? Check out our compilation "Skills for Successful Product Owners"
Content of 1-Pager:
User Stories – Capture requirements as User Stories – Concise and easy to use!
In agile environments you reduce big upfront design, because you know that customer requirements will change. Capturing requirements as User Stories is the most common approach.
A User Story has 3 components (3Cs): The physical Card contains title and description. It’s a reminder to have a Conversation to create a shared understanding between everyone involved. You discuss what is really needed and agree on acceptance criteria to Confirm that the team
achieved the benefit.
Classic format:
As a <role>
I want <goal>
so that <benefit>
A User Story contains:
- The Role – Who wants something. Ideally a customer (persona).
- The Goal – What does the customer want to do?
- The Benefit – Why the customer wants this. What does she want to achieve? This is the most important part of the story, because you may discover that there’s a better way to reach the benefit than the <goal>
Focus on benefit:
In order to <benefit>
as a <role>
I want <goal>
Example stories for a CMS:
- Bad: “As the database I want a field ‘status’ so that I can store if a post is a draft or published”
Databases can’t want anything. What’s the benefit for customers? - Good: “As an author I want to save posts as drafts so that I can finish them later”
Sources:
1 Pingback