A workshop on writing User Stories in Pivotal Tracker

1. Storytime with Jason
This workshop was delivered to an audience of internal Pivotal Staff and visitors from various startup companies
in Singapore, July 2016.
This deck has been altered to include the presenter notes. (not pretty, but more functional)

2. Storytime with Jason
@jfraser

3. Once upon a time...
Thinking big is not at odds with starting small.
- Eric Ries, The Lean Startup

4. What is a User Story?
A document of the smallest verifiable unit of
customer value that we can deliver and test.
A user story is a description of a piece of functionality. It documents the outcome of a conversation and serves as a physical reminder of
intention and a placeholder in a backlog (which allows us to prioritize it.)
This is my favorite definition: a document of the smallest verifiable unit of customer value that we can deliver and test.
Customer = Whoever is using it/trying to get value out of the interaction.
How do we use a user story? What do we do with it?
Show to stakeholders
Plan at epic level
Prioritize functionality
Execute acceptance tests
Share across the team so that people know what to build

5. Molecule
How do we get there?
We start with a product vision: A user, with a problem, and our solution to that problem, our “Value Proposition.”
Each of these are subject to more or less validation, and that’s a topic for another workshop, but once we have a
validated value proposition, we need to figure out what all the components are which comprise that value
proposition.

6. Feature Ideation and Prioritization
Review the value proposition
Brainstorm
Self Edit
2x2 Prioritization
Ideally the next step is to brainstorm and prioritize features. What are all the things we need to do in order for our
customer to receive value from our product?
Often this first pass at brainstorming delivers a mix of epics and features, but a bit heavier on the epic side.

7. Scenarios
Need
SeeFeel
Do - @kimsheblue
From here, we move into scenario writing. What
do people need when they engage with our
product? What do they see that allows them to
fulfill that need? What do they do with what they
see? How do they feel about it?
We go through this cycle over and over until we’re
through an entire happy path.
We use a balanced team for this whole process,
which means everyone on the team has had the
conversation about who the user is, why they
need this feature, and what the outcome is for
them.
Each of these cycles in a workflow turns into a
user story. My preference is to turn them into
wireframes first and write the story based on the
wireframe + Scenario.

8. What are the qualities of a user story?
Independent
Negotiable
Valuable
Estimatable
Small
Testable - @mikewcohn
A user story should be:
Independent: obviously this is an ideal, and sometimes if we’re clever about how we write our stories we get some
things for free later, but we want to be able to prioritize our stories according to user value, not order them based on
dependencies.
Negotiable: we do not specify how to engineer the story. And we have conversations about implementation details,
what’s hard about the story, what could we change to deliver the same value with less effort, etc.
Valuable: If we cannot articulate the user value of this story, we probably shouldn’t do it. There’s no such thing as a
“backend story.” If you need to migrate a database, you do it as a part of the user value driven story that necessitates
the migration.
Estimatable: If your engineers cannot estimate the story, either they were not included enough in the story creation
process, or the story is too big and needs to be broken down. In some cases you may need to create an exploratory
chore (spike) to learn more about the technical intricacies before you can estimate. This is ok, but you have to end up
with an estimatable story.
Small: A User story should be small, as small as it can be while remaining valuable, independent, and testable.
Testable: We should be able to go through a set of acceptance criteria to make sure that the story is functioning
properly and doing what we want it to do. If a story isn’t testable, it’s probably too small. Going back to our example of a
database migration, as a normal user, I can’t go in and test that this has happened, but I can verify that the feature that
drove the necessity for the migration is functioning, and if that feature isn’t functioning, probably there’s a problem with
the migration.
This mnemonic comes from Mike Cohn, who wrote a book on it in 2004: User Stories Applied. I have not read it.

9. What is a user story made of?
Title
Story
Acceptance Criteria
What we call a story in everyday parlance is actually made of three things, of which the Story is only 1.
A good Story has a title, a story, and clear acceptance criteria.

10. Title
Persona
Verb
Object
Titles should be descriptive.
They should contain the persona, and the thing the persona is doing. And sometimes an object. I’ll show you what
I mean.

11. Persona verbs (a thing)
You have a persona, in this case KATE, and that persona takes an
action. Sometimes the action has an object (Kate Creates her
Collection) and sometimes it’s just a verb: Kate Signs out.
Sometimes you need to add a context if a certain action can take place
in more than one context: (Kate Creates her first collection while
onboarding) to differentiate it from Kate Creates her first collection
independently or as part of a different flow.
We try to avoid the word “can”. It adds ambiguity to the story. I don’t like
“Should” stories either, but many do. Should stories are at least clear in
terms of intention, but still not as clear as the
non-subjunctive/non-modal verb form.
Here’s an example of the ambiguity of Can: If I say “Sandra can jump
off the cliff” I don’t know if that’s a good thing or a bad thing. If Sandra is
a base jumper, and we’ve created an affordance for her to get access to
the edge of the cliff, maybe we’ve cleared some bushes or something,
this could be great. But if Sandra is a depressed teenager and the cliff
is on the grounds of a psychiatric hospital, we might be describing an
issue that we want to correct.
I should be able to look at the title and clearly understand the intention.
Our whole team should understand Sandra already, and understand the
value we’re trying to create for her, but we still want to be as clear as
possible in writing it up. Eliminating words like can and should also
serve to make the title more concise.

12. Now You Try It!
Here’s a wireframe that I used on a recent project.
My persona is an administrator named Danielle. She gets to add people to a class of users called Data Stewards.
There are privileges that come along with these classes.
The story we’re writing creates this page and its assignment functionality. Assume the header is already there, so
you don’t have to worry about that.

13. Now You Try It!
Persona
Action
Object
Remember, a story title starts with the persona name, followed by the action, and the object of that action (if there
is one). Take 2 minutes to write your story title.
Then talk it through with the person next to you. For 4 minutes
Let’s share with the group then: Who has a good one you want to share?

14. What did you have?
Here’s what I have for this one. How does it compare to what you have?

15. Story
Persona
Action
Value
Next we get to the actual STORY PART. The story is a simple statement: As [PERSONA], I want to [ACTION], so
that [VALUE]

16. The Persona verbs (a thing)
Here’s an example.
Our persona, Kate, is validated. We know she’s a good
representative of our user. We’ve talked with her about dealing with
personal data, and we know she wants it to be kept safe. She
doesn’t want anybody messing with what’s stored on our product.
There’s some philosophical debate about whether Kate actually
wants to sign out or if she just wants her stuff to be safe. We’re
forcing the desire of the implementation on her. I think this argument
is largely academic. Nobody wants to use software, but we’re forcing
that implementation on them because it’s currently the best way we
can imagine to solve the problem at hand. That said, you should
never settle for a user story that says “As Kate I want a feature so
that I have that feature.”
What doesn’t work is: “as Kate, I want to keep my data safe so that
nobody gets access to it.” These two are logical equivalents, and
nobody getting access to the data doesn’t articulate the value of
nobody getting access to it.
Or something like “As Kate, I want a print button so that I can print”
is not an articulation of the value that printing provides. What would
be better?
(As Kate I want to print my collection so I can go through it with my
father-in-law and mark it up with a sharpie)

17. Now You Try It!
Back to our wireframe.
We’ve got half of this already. The story starts with a persona too, so just like your title, that’s Danielle.
What’s the value for Danielle in assigning these roles? If we had done all the research together you’d know. But
we haven’t. So I’ll tell you: Danielle wants to make sure that only the right people have access to certain
privileges. She doesn’t want her data messed up by inexperienced people.

18. Now You Try It!
As X
I want to Y
So that Z
Remember, the story starts with “As” followed by the persona name, followed “I want to” do the action, “So that” I
get some specific value out of it.
Take 2 minutes to write your story statement.
Then talk it through with the person next to you. For 4 minutes
Let’s share with the group then: Who has a good one you want to share?

19. What did you have?
Here’s what I have for this one. How does it compare? I gave you two statements of value. Which did you
choose? I’d actually change this one: I think the real SO THAT statement here is so that my data doesn’t get
messed up by inexperienced people.

20. Acceptance Criteria
GIVEN
WHEN
THEN
AND
(and sometimes) IF
Next up is Acceptance Criteria.
We write our acceptance criteria using a very specific syntax
called Gherkin.
If you look up Behavior Driven Development (or just Gherkin) you
can find more information about the history and application of
this.
Gherkin uses a very specific set of logical operators: Given,
When, Then, and And. Sometimes IF (if you have multiple
scenarios)
https://github.com/cucumber/cucumber/wiki/Gherkin

21. Gherkin
This is from an article on Github: https://github.com/cucumber/cucumber/wiki/Gherkin
Writing your acceptance criteria this way makes them very clear. It gives you your context, the actions to take, and
the expected and verifiable outcome.
If you follow the gherkin and it doesn’t resolve properly, then your story is a reject.

22. Gherkin in Practice
And here’s what it looks like at Labs.
When we write a story like this, the expected outcome and the method of achieving that outcome (how to demo
the feature) are encapsulated in the same block of text.

23. Now You Try It!
Given
When
Then
And
Back to our wireframe.
How do you think we’d accept this story? What has to happen? Take 3 minutes to write your acceptance criteria.
Remember, you set your context with GIVEN. It tells us where we’re starting. Where are we? (you can call this page whatever makes
sense to you). In this case, we’re creating a new page, so we want to describe what we’re seeing. Use an AND for that. Next is WHEN,
when I do some action, THEN something happens, AND I can verify it.
Then talk it through with the person next to you. For 4 minutes
Let’s share with the group then: Who has a good one you want to share?

24. What did you have?
Here’s what I have for this one. How does it compare?
This one was tricky. Some of that trickiness would have
been cleared up if we had all written the scenario
together. But let’s go through it.
Given I’m where? On the role assignment page.
And what do I see there? A list of users
What do I do? When I toggle a switch one way
Then something happens: The user gets permissions. I’m
going to have to verify that, and whether you include this
or not depends on how sophisticated your client PM or
PO is. You may need to spell it out. Anybody have any
thoughts on how you’d do that? (AND WHEN I log in as
Michael, then I can execute some restricted function that
I couldn’t do before)
I usually like to write things like this so that they can be
reversed in the same story. Like adding a CANCEL
button for an action confirmation. You can work with your
engineers to decide if that’s the right thing to do on a
case by case basis.
You may write a note here or there. In this case we
included the set of specific permissions the Data Steward
gets, but all of those abilities had been created in other
stories.

25. The Big Picture
When stories are completed, they’re taken into our iteration planning meeting, discussed, estimated by the
engineering team and finally placed in the backlog and prioritized according to highest value.
There are a few conflicting schools of thought on backlog and icebox management, I won’t get into those here. It’s
a topic for another workshop.

26. @jfraser
Thank you
Terima kasih谢谢
ந றி