Storytime with JasonThis 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)

Storytime with Jason

@jfraser

Once upon a time...

Thinking big is not at odds with starting small.

- Eric Ries, The Lean Startup

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 stakeholdersPlan at epic levelPrioritize functionalityExecute acceptance testsShare across the team so that people know what to build

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.

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.

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.

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.

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.

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.

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.

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.

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?

What did you have?

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

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]

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)

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.

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?

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.

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

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.

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.

Now You Try It!

Given

When

Then

AndBack 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?

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 usersWhat do I do? When I toggle a switch one wayThen 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.

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.

@jfraser

Thank you

Terima kasih谢谢

ந றி