Over the last 18 months, we’ve built up a lot of confidence in the method below. You’ll see how I write stories, what its done for our team, and how to make sure it works for yours. So let’s start writing… Get a better quality version of the PDF: https://www.dropbox.com/s/lkdd7reqi75bhb6/FrameworkModernUserStories_JonDobrowolski.pdf

1. A framework for
modern User Stories
All you need to know about the anatomy of a
User Story with examples
By Jon Dobrowolski
https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm

2. The User Story is a maturing customer-focused
software development mechanic.
However, confusion continues regarding the
tactical writing of modern Stories
• ‘How much is too much detail?’
• ‘Should it be as complete as a spec?’
• ‘What’s really needed for context?’
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm

3. You’ll see how I write stories, what its done
for our team, and how to make sure it works
for yours.
So let’s start writing…
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm

4. Begin with an example
Let’s get a feel for the structure with a sample behavior and its
corresponding Story. Say you’re working on a site like Medium and you want
to add a button to save articles…
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm

5. User Story elements explained
Let’s first take a look at the anatomy of this Story. Some things may look
familiar to you…
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm

6. “Every story title should include the word
‘should’. NEVER use the word ‘can’, which
camouflages desired behavior. E.g. It’s unclear
whether the story ‘User can delete comment’ is a
feature or a bug. ‘User should be able to delete
comment’ or ‘User should not be able to delete
comment’ are much clearer: the former is a feature,
the latter a bug. Don’t make me guess.” — J. Berger
Story Title
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm

7. Original User Story format goes “As a <role>, I want
<goal/desire> so that <benefit>”
We use ‘because’ to frame thinking around why this
feature needs to exist and find that it sparks
something (honesty) more effectively than ‘so that’.
More on the genesis of the traditional User Story here.
Traditional User Story
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm

8. • Also known as “Given, When, Then” statement,
or “Acceptance Criteria”
• Included to strengthen the traditional story
• Imply behavior driven development / design
(BDD)
User Scenario (the fun part)
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm

9. Writing your Story with BDD in mind creates a
common language abstracted to accommodate
business stakeholders, designers, developers
and product managers
Simple but surprisingly powerful
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm
User Scenario (cont’d)

10. Acceptance criteria should be written in terms
of scenarios.
Given [initial context],
when [event occurs],
then [ensure some outcomes] —Wikipedia
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm
User Scenario (cont’d)

11. • User Stories can contain multiple User
Scenarios within them
• If you see yourself writing a large number
(>3 or so) - story should be broken down
into smaller parts
User Scenario (cont’d)
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm

12. • ‘And’ can be used to augment User Scenario
for semi-obvious changes in the system when
Scenario runs its course
• Use with caution — can sometimes imply
functionality that should be broken out into
its own Story
User Scenario - ‘And’
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm

13. Example including ‘And’
Taking a look at how the ‘save’ function works on Medium, you see that the
button’s state changes to indicate that it has been ‘saved’ successfully.
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm

14. TIP: Stories can usually be estimated without light dependencies (final
copy, final design, etc) if your team is in tight communication.
• Links to design files
• Copy needed
• Prototype URLs
• List additional stakeholders, etc.
• Not included in the main Story as details can
be variable
‘Info’
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm
‘Info’ portion of the Story provides any
loose context, such as…

15. • Provides uniform structure to the Story
• Anyone on the team should be able to open a
Story and know exactly what to expect
Why do it this way?
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm
Sifting through unstructured information does
not get your team excited about building.

16. TIP: Old Stories are revisited to reference in new Stories,
to get people the context they’re looking for, or to remind us how
we did something.
Tips for Success
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm
• “A user story is a placeholder and a
promise to have a future conversation about
the needed functionality.”
• PdM’s are responsible for priority, but by
no means responsible for all Story writing
• Entire team should feel empowered to write
and ask for feedback
• Good User Stories become documentation

17. More Info
Jon Dobrowolski https://medium.com/@jonatisokon
http://linkd.in/1D9QVWm
• Shareable Medium article
• StoryScrip - A User Story boilerplate for
Pivotal Tracker
• Product Mgmt By the Book