Transcript
Let's talk about user stories.
User stories are here as a requirements technique on projects.
Generally, agile projects, but I think user stores work well even on traditional projects so we don't have to just do this on agile.
Use your stories here to help with a requirement challenge.
In a software project, those who want some software Need to communicate with those who are going to build the software.
And in that communication, there are a couple of problems.
A couple things that can go wrong.
Want to touch on these things, that need to be in place.
The first is that the balance of power has to exist.
I don't want to have a situation where the business is dominant.
or the development team is dominant.
There has to be a balance of power between the business and the developments side.
If either side is dominate, we end up with some problems.
if the Business is all powerful, they walk into the developers and say things like, I need this, i need it by this date,
make it so.
Now that may sound fun if we're the business, we might think that sounds fun, but here among friends we can say that's clearly not the right way to get
the best product built.
It's not going to be good to walk in and say, make it so, I need this, so.
So we don't want to necessarily be in a position where the businesses gets to dictate everything.
On the other hand, sometimes we see organizations where the developers are dominant.
In those situations, what we say is the developer is replacing the language of the business with their own.
We make the businesses speak our language.
Will build whatever you want, but you have to fill out this complicated use case template.
Fill this out and that will tell us what to build for you.
If you don't fill this, out we won't build you the right thing.
So when we do that, when, we force the business to speak technology's language, We lose the opportunity to hear from them in their own words,
because they're having to translate things into our templates and our language.
And so we lose an opportunity hear, from the, business.
so the first thing that can go wrong is this balance.
Second challenge or second thing that can go wrong is the question of resource allocation.
Resource allocation has to be a shared problem.
Businesses often, perhaps even almost always, want more than they can get in a given time.
I need this.
I can't give you all that by September.
Businesses often want more than we can give them.
This is a resource challenge.
How can we best use our resources to give the best amount?
Well, I want there to be a balance here as well.
Resource allocation, the shortage of scarce resources, cannot entirely be the development team's problem.
It can't be entirely the business's problem either.
We need some balance here.
If we make the development team entirely responsible for solving the problem of scarce resources, the developers will often make bad trade-off decisions.
Our programmers may look at something and think, well, OK, negative data is never going to get here.
I don't need to code defensively.
Negative data can't possibly make it to this part of the code.
And then, of course, we know negative date does get there.
Now, I don't know that that's a bad decision.
It might have been an OK decision, but the point is it shouldn't have a decision that the programmer makes on their own.
That should be more or less a combination, a joint decision programmers shouldn get to decide where we take shortcuts.
Similarly, if we make the problem entirely the businesses, We see a different set of problems.
If we make the problem of scarce resource entirely the business's problem, this is where we see the great big spec document,
great, big specification come in.
Think about it this way.
As software developers, we like to make fun of the 300 page specification.
But no business person ever said, hey, I want some software.
I'd like to write a 300 page document.
They don't like that document any more than we do.
We're the ones that make them write that.
we tell them, we will build whatever you want.
But you better not change your mind.
If you change our mind, We will make it expensive for you.
So get it right.
And we introduce the great big specification document, and we make then fill that out.
This leads to, essentially, the waterfall process.
If you're familiar with the water fall process, it's essentially do all the analysis, do the design, all of the coding, put the whole system into operations.
Well, that's the hypothetical waterfall.
Here's a real-world waterfall that we see.
I like Donald Reinertsen calls it the fuzzy front end.
We got the Fuzzy Front End, then we got some sort of construction phase, and then the last phase of the waterfall process,
the rapid de-scoping phase.
Just rapidly drop all the things we're never going to have time for.
Rapid de-scoping.
That's what we see in the real world.
This is clearly not the right way to build software.
Third problem, our depressing start to the session, third problem.
Imperfect schedules.
If you know this, but I've written a book on estimating and planning.
But I'm going to say that estimatin' and planin' software projects is notoriously difficult.
Very difficult, right?
If we can't perfectly predict the schedule, it makes it very hard to have discussions about what should be in, what'll be,
in what won't be.
It's very to hard have those trade-off decisions, that kind of what if analysis, if we cant predict a schedule.
All right, very difficult So what do we do about all these things?
We make decisions based on the information we have, but we do it often.
And rather than one all-encompassing set of decisions, we spread decision-making throughout the project.
We avoid making one big set decisions upfront.
Here it is.
It's all documented.
This to me is where stories come in.
Stories are gonna help us do those things.
Story are going to help overcome those problems that we just listed.
Let's see what stories are.
To start with, let me grab something over here.
What stories are?
Ron Jeffries is one of the three guys who originated the extreme programming process.
Extreme programming is on of agile processes and user stories come to the rest of Agile world including Scrum and other processes from extreme programing.
Ron has written about something he calls the three C's.
Three Cs of a user story.
The first C is the card.
I've got these little index cards here.
And so when we think about user stories, we thing about writing them on these cards.I love these things.
i like that I can take these into meetings, I could spread them around on a table,I can turn them sideways or up on their end if I want.
So maybe a card this way means bug.
A couple months later, we get together for a different meeting.
Maybe a card turned this way means something the company CEO announced at the annual users meeting, right?
I like that I can rip them up.
I like that these things do not feel as permanent.
Things go into a software system, they feel permanent and we don't ever want to delete it.
So I love these thing as a tool and I was very opposed to these at first.
When I first started doing ads, when I came across stories and product backlogs, I'm a Software Guy.
I am not going to use these.
My grandmother wrote recipes on these.
Your guys' grandmothers do that, too?
Does that happen here?
My grandma wrote recipe on this.
I'm not going to put software features on here.
That's silly.
And so we built systems for this, and then later I had the first team I worked with that was using cards.
Wow.
Very powerful technique.
There's something about being able to have your hands on it that makes it more powerful.
We interact with it differently.
So Ron wrote about three C's, the card, and the conversation.
The conversation is this, a programmer grabs a card ready to go work on this.
Programmer grabs the tester.
And the programmer and tester walk over and talk to someone called our product owner or key stakeholder.
We say, hey, product owners, tell us more.
What is this story about?
What do you want?
How should it look?
And so the conversation, probably the most important part of the three C's I'm going to build up here.
I'll add one more C.
Conversation, the probably most In that conversation, the card serves a couple of purposes.
The card to me serves as a reminder or a promise to have the conversation.
Think of how powerful that promise is.
It is a promised from the team to the product owner.
We will come talk to you before we start.
That promise what frees the Product Owner up to not write every last detail down on here.
If the Team might start this thing, before they have a conversation with the product owner.
As the Product Owner, I'm going to feel compelled to not just write this little bit on a card, but to write a specification document and staple it too here.
Because the team might get started on there.
I better write a full-on spec and put it with this.
So the promise to have a conversation.
Now, the card is not a requirement.
Don't think of the user story as a requirements.
Think of a user's story is a pointer to the requirement, kind of programming term.
The requirement might be elaborated in a conversation.
The product owner talks to me and tells me what I need to know.
Maybe it's a workflow diagram, a little Vizio diagram.
Stapled to this.
Maybe its a math algorithm.
Do it this way, here's the mathematical prototype.
May be it a UI design, stapled to here.
So I think of the card not as a requirement, but as pointer to the requirement.
One more C.
Find my mouse.
Behind me, there we go.
Third C, conversation.
We go to the product owner, we talk, or confirmation, I'm sorry.
I was getting backed up.
Confirmation.
The third C here, confirmation.
This is the acceptance criteria that we use to judge when a story is done.
When I was 17, I as in the last year of what we call high school.
I don't know if you guys call it, what is it?
Is it gymnasium here?
Gymnasia?
So I'm 17. In the year before I go to university, and I had a literature teacher.
And she said, write a paper on Macbeth.
We'd been reading MacBeth in class.
She says, Write a Paper on McBath.
Boom, my hand goes up.
How long does it have to be?
And I asked Ms.
Nelson, my teacher, Ms Nelson.
I said, how long does it have to be?
And she just ignored the question and just kept lecturing.
And, I waited a few seconds.
Ms, Nelson you didn't answer my question.
How long will this paper have be.
She said I'm not going to answer that.
OK.
how does need to if I want a good grade?
I figured I'd try it a different way.
It needs to longer than if you want to a bad grade.
Ms.
Nelson, how long would it be if you wrote it?
Oh, it would be the right length then.
I don't know how I got her to give in, but she finally gave in.
And she said, Mike, just make it five pages.
Just make a five-pages.
You can tell I'm bitter about this all these years later.
I contend that that was part of her job was to convey her expectations to me.
That fact that, that paper had to be five pages were part her acceptance criteria.
Right, if I had turned in a half a page on Macbeth, and let's suppose for a moment it was brilliant, it wouldn't have been,
but let suppose it brilliant half page MacBeth.
No way was I gonna get a good grade.
Supposing it 50 pages on McBath.
No way would that have been brilliant either.
If I had turned in 50 pages, she might have written down a couple of good thoughts in here, cut out the junk next time.
Give me a bad grade on that too, F.
So she had an expectation.
She should have shared it with us.
Our product owners have expectations.
That's what we're after here with confirmation.
How will I judge this story when you're done with it?
It's our acceptance test.
Macbeth paper has to be five pages.
User story has be such and such.
Let's see a a few example stories.
As a user, I want to reserve a hotel room.
This would be from a travel website.
I don't reserve hotel rooms.
As the user I went to cancel a reservation.
Let's see one more.
as a vacation traveler I can see photos of the hotels.
Now, notice I did something different here.
The first one and second one were as a user.
This third one, as vacation traveler.
We embed the type of user in the story so that it can provide some context.
As a vacation travelers, not as business traveler, right?
I'm here this week as the business travelers.
I didn't spend any time looking at what hotel to stay at.
And I asked the conference organizers, I said, where should I stay?
They said which hotel?
And booked the reservation.
My family came over here.
We were here two years ago.
And we spent about five weeks in Norway.
we had this grand plan, see Norway, right?
And then you start to plan it.
It's like, OK, let's see the middle of Norway So we did here to Bergen, Lillehammer, Trondheim and back, and so we're arguing about next year,
do we go north or do go south?
So, we are arguing that for next years holiday.
But when we planned that trip, We came here two years ago.
We actually tried to come here three years, but my wife got so caught up in trying to make sure we picked the right hotels and the cities.
How can you see?
We had the plan to see Norway, and you couldn't.
And so she spent so much time picking out hotels.
She did a great job.
But a vacation traveler is going to look at photos of hotels, right?
I'm a business traveler.
OK, I am teaching at the conference center here.
Oh, there's a hotel connected.
I'll stay there.
All right, didn't look photos.
Of it I just stayed over there, all right.
One more story.
As a frequent flyer, I can rebook a past trip.
I flew over here on Friday, so it was May 31st or something.
Why in the world would I want to rebook a trip from Denver to Oslo on May 31, 2012? Does that make any sense?
Rebooked a past trip.
Does it make sense.
Sometimes the story doesn't make since until we add what is called a so that clause.
Let me add one here.
So that I save time booking trips I take often.
I love coming here, I'm fortunate enough to be able to come over to also four times a year.
But I would love it though if I could go onto a website and say, Give me the usual, please.
And it booked me Denver to Chicago, Chicago to London, London to Oslo, Oslow to Frankfurt, Frankfurt to Denver.
I'd love it if it could book that for me with one click.
All right?
I'm a frequent flyer.
Rebook a past trip?
Yeah.
Not the same date.
Of course not the date, right.
I consider the sew that clause to be optional here.
You'll notice I didn't have it on the other ones.
As a user, I want to reserve a hotel room.
I don't really need a sew-that clause there.
There's only two ways I can think of to end that sentence, and only one of them is moral, right?
So I don't really need to sew that clause there.
I consider it optional.
But from these four stories, you can kind of infer the template I like for writing stories.
Like to write them this way.
As a type of user, I want or I need or can, or am forced to, something like that.
And then optionally, so that and some reason.
The sew-that clause is sometimes very helpful in telling us why somebody wanted something.
Oh, that's why you want it.
OK, can give that a completely different way, in fact, we already support that in the system.
So the sow that clause to me a little bit optional.
Now in these stories, where are the details?
These things are short.
We only have this little tiny card.
Where do the detail go?
Let's think about this story about I can cancel a reservation.
I'd have a lot of questions.
I walk over and talk to my product owner and I've got questions Does the user get a full refund or a partial refund when they cancel?
Is the refund policy the same at this Radisson as the Radison by the airport?
How about the radison buy the old airport, right?
is it the Same cancellation policy at all Radisons right how far ahead does the User have to cancel their reservation?
I don't have A lot Of questions So our question is, what do we do with all the answers?
A couple of things.
One thing we can do, with those answers, is we use them to write what are called conditions of satisfaction.
Conditions of Satisfaction are essentially test cases, high level test case.
What I like to do is I take a user story, I can cancel a reservation, and then quite literally turn it over and on the back write our high-level acceptance test.
All right, let's think about my English literature teacher a moment ago.
Write a paper on Macbeth, on the back must be five pages, all right?
So the bag of the card has the acceptance criteria for this.
So in this example, we might have acceptance criterion like these.
Verify that a premium member, somebody who joins our website, can cancel the same day without a fee.
They verify that non-premium members are charged a free, Verify that we send an email out and verify that the hotel's notified that they have a room available again.
Those would be my essentially acceptance tests.
Okay, I use the phrase acceptance test.
So why am I using this weird phrase up here, condition of satisfaction?
Here's what I found.
If I walk into my product owner's office and I say, hey, product donor, tell me your acceptance tasks.
Who do they tell to me to go talk to instead?
Tester.
They say, go talk to a tester.
So I'm a busy product owner.
You're here to talk about tests?
Get out of here.
Go talk a to tester, right?
And I don't want to to test her.
Well, that doesn't sound right.
I Don't mind talking to the testers, but I want get the conditions of satisfaction.
Want to get high level answers straight from my product owners, not a tester.
The product owner is the one who, a couple of weeks from now, at a sprint review or iteration review, is going to sit in judgment of this user story and say,
it's done, or it is not, go change it.
So I want to know their acceptance criteria.
What I found is by using a slightly different phrase, hey productowner, tell me your conditions of satisfaction.
I get better results.
So a slightly different phrase.
Sometimes the words that we've used for years have loaded meaning.
Find that especially with things like beta test.
Beta test means such different things to all sorts of different people.
It's kind of a hard phrase these days.
I go to my product under a different phase.
Tell me your conditions of satisfaction.
What do you need to see to be satisfied with this?
The end of the sprint, I mentioned that we do an iteration or sprint review.
One of ways to know that you're writing those conditions of satisfaction at the right level is this.
Think of them as the script for the Sprint Review.
Two weeks from now, three weeks, whatever it is, you are going to demo this user story to your product owner.
Those conditions on the back are the Script.
Those are the things I'm going to want you to show your product owner.
You're going walk through, you're gonna show them.
That's why when I do this I actually quite literally with cards I will draw that little box here.
I don't draw a bullet, I draw little check box.
Then when i'm giving my product under the sprint review, i check it off.
Okay we've shown you this, we're showing you.
This that becomes the script for the Sprint Review.
These are essentially high-level tests.
i just use a different phrase.
So I'm going to back up here.
We said we're talking about detail.
How do we add detail?
We go have a conversation, product owner starts laying on us a bunch of detail, one way to capture that detail tests on the back.
Another way add to detail is to use smaller stories.
So we have story here, I can cancel a reservation.
I ask my product owner what that means.
I get a lot of detail out of my project owner and I decide to write smaller stories.
In this case I might write the stories as a premium site member I can cancel a reservation up to the last minute.
As a non-premium member, I cancel but I'm charged 10%. As the site visitor I am given an email when I canceled, things like that.
So I could write small stories, that's the other way to get at additional detail.
I want to point out something that I think is pretty subtle, but I thing is very important.
Look at the user stories up there.
Premium member can cancel, non-premium members charged.
I'm going to back up a slide.
So here are those conditions of satisfaction on the back.
They're the same, OK?
These two techniques are essentially two sides of the coin, right?
We can write smaller stories.
I can right conditions of satisfaction on the back.
Both techniques or the say.
The effect is different.
And I end up with more stories, or I put tests on back of this story, but the technique being different, we get the same result.
It's a way to add detail.
Now you don't need today to decide which of these approaches you like.
You like this approach.
you Like writing tests on the back.
Meanwhile, you got a co-worker back in the office reading a book about Agile, and your co worker decides that he or she likes writing smaller stories instead.
And now you've got problem.
If you liked one approach, your coworker likes the other.
Not really a problem, You're going to use both.
When you have a great big user story, the natural thing to do will be to turn it into smaller story.
When you have a story that you've turned pretty small, the natural thing to do will be turn it over and write tests on the back.
So we're going to use both of these approaches, okay?
You'll use of both these approach, which is what this slide is saying here.
You're gonna use to both approaches.
It's gonna be a natural think.
I pointed out here to make sure you're aware of it, but you are going do both things that will happen naturally.
Okay?
I want your product backlog to look like an iceberg.
I don't want your backlog to look like an iceberg.
Now, what I'm talking about here is I want small things at the top of your back log.
Small, detailed things.
Those are coming into the next sprinter iteration.
They have to be small enough we can do them in the couple weeks.
But we've got other things we're not going to do for a while.
We might not do it for six months or a year.
I wanted those to big, vague.
All right, we had a travel site up there a minute ago.
Let's think about a Travel Site.
Let's think about orbits.
I've never worked with orbits, I haven't worked for three travel sites.
Haven't work with orbit, so I'll use them as an example here.
Let us think of about this.
A guarantee that orbits has a product backlog item.
They have something that says, as a traveler I would like to book a cabin on a cruise ship.
Orbitz doesn't support cruise ships.
But somewhere, they have a requirements document or a backlog that says, do cruise ship, but they've been in business for 10 years or whatever and still
never got to that.
It would have been a waste for them to write that as a very detailed set of user stories.
The right thing for then to do, if they haven't done it yet, just leave it alone, great, big, huge user story at the bottom of their backlog.
Someday, orbits will finish all their other higher priority travel site stuff, and they'll be sitting around and this story will have moved from the bottom
to the top.
And they will be, hey, let's do it.
Let's finally do cruise ships.
We've done everything else.
But until it moves to top, It's a waste of time to invest in that backlog item.
I don't want to add detail to it when it's not important.
So if we think about a real world iceberg, not our product backlog iceberg.
Think about real-world iceberg floating out there in the North Atlantic.
Helicopter flies over and lifts off the top of the iceberg for some reason.
What happens to the remaining part of iceberg?
What's it going to do?
It's going to float up, thank you, it's gonna float.
There's less weight pressing it down, and it floats up.
I like that as a metaphor for our backlog here.
It points out a couple of things.
New things are becoming visible at the bottom.
The iceberg floats, new things become visible.
We've got a flat spot at top of the backlog, we have to do something about that.
Here's what we're going do.
We're going to take things that are in the middle of the backlog and break them into smaller pieces so that we now have a suitable set of small things
at the top of our backlog.
This is something that Agile teams call grooming the backlog.
Grooming the Backlog refers to keeping the backward in good shape.
We groom the backpack.
All right, we make sure that every sprint or every iteration we're spending a little bit of time Keeping the backlog in good shape so that we end up at
the next sprint planning meeting walking in and we've got small things at The top ready to do we don't want to walk into the Next sprint planting meeting
and have those great big things in the bottom.
All right, then we say what do?
We do and somebody says cruise ships.
Oh Gee, you know, what we have to for a cruise ship.
What's it gonna be like?
How are we gonna do this?
so we to have a little bit of this grooming going on to keep the back log in Good shape And thinking about your product backlog iceberg,
I want to introduce a couple of terms here.
The first term, epic.
Epic just means great, big one.
Typically means bigger than a sprint, bigger that fits in one iteration.
This is going to take us more than in a few weeks to do.
Now, over here in this part of the world, a lot of times people, teams will call this a saga instead.
I'm fine with that.
Saga, Epic, whatever.
Just means big.
The other term I want to introduce here is theme.
A theme is a group of related items.
So suppose we're sitting around in orbits and we decide, hey, let's do cruise ships.
And so we take our cruise ship story, it's a great big one, I mean epic, All right, I rip my epic up, and I write a bunch of smaller stories that all have
to do with cruise ships.
So we write all those.
We do all that work.
we get a whole bunch stories written.
And then somebody walks in and says, oh, great idea.
Let's change how we do hotels.
Really do this instead.
What's not do the cruise ship stuff?
Well, darn it.
I just spent all the time writing all of those stories.
Well here's what we're going to We're going to take those cruise ship stories, put a rubber band around them, and then we're gonna put them back in our
shoe box or wherever we keep our stories.
And we want to treat that as essentially one thing.
All right, it's got a rubband around it.
It's really only one think.
I don't got to look in here at all the things.
Now I'm just gonna write on top of this theme, I mean, to write cruise ships.
So a theme is a group of related.
Think of it as a staple or a Rubber Band around a Group of Stories.
An epic, one big one.
two terms that we use.
Now I want to give you an example.
As an examples from one of my clients, these guys are in two cities in the US, one city in India.
They make software for large retailers, so big stores.
So here's one their stories.
as the vice president of marketing at a store, I wanted to review the performance of historical promotional campaigns so that I can identify and repeat
profitable ones.
Basically, the story here is saying I'm the vice president of marketing.
How should I spend my ad budget?
I don't want to know how to spend by ad-budget.
I asked the team how big was this.
And I said, I want know your estimate.
That's too hard.
But if I were to ask you to estimate this, would you come back with an estimate in hours, days, weeks, months, or years?
So what type of unit pops to mind?
Because even if you had to do that, just seat of the pants type thing, and they said oh, many, OK, this is clearly an epic.
This is going to take lots of weeks.
Clearly an Epic.
So let's split it up.
I asked the team to split up, here's what they did.
As the VP of Marketing, the top one, I want to select the time frame to use when reviewing the past promotional campaigns.
The bottom one, I want to select the type of campaign.
Radio, direct mail, email marketing, television marketing.
This is a good split between our stories here.
The top one was selecting the date range, the bottom was the selecting type.
What's nice about this is these stories were independent.
We'd like to have stories that are independent, right?
I could do the top or the the one.
I can do these in either order.
Suppose we did the first.
If we did the top one first, the team could select a time frame to use.
They could say, show me the summer season, or show just Easter, Or show June for the last five years.
But they would get June, for all types of advertising.
Radio, television, email, print.
If they did other order, if they do the bottom one, first.
The team can say show only email advertising, But they'd get it back through the dawn of time.
So these stories are independent.
We could do them in either order.
It's a good split.
I asked the team, how big were these?
I said, are these epics?
Bottom one is.
Bottom is still pretty big.
so we split the bottom one up.
Here's how we've split, the Bottom story.
As VP of Marketing, I can see information on direct mailing, another one about television ads, and another about email ads.
This is an example of this story starting out at the top of the backlog, moving up, Eventually, something like TV ads would get to the top of the backlog.
At that point, we'd turn it over and write its conditions of satisfaction on there.
Conditions of Satisfaction for a television ad story would be things like, I want to know how many people watched it last night.
I wanna know, how may of them were in this income bracket.
How many of them were 18 to 25 years old?
That's our target audience.
I'd want to know things like that about our television.
Very different than what I want know about email ad.
Email ad, I wanna know click through rate, bounce back rate.
Things like.
Different conditions of satisfaction.
So let's talk about writing user stories.
Let's see if we can yell some of these out.
I want you to think about this and see you can help me out here.
Suppose we have a login user story, right?
We have story that is about logging into the system.
We want to see we could write some these together.
Help me figure out a couple stories.
And here's some examples.
As a registered user, I'm required to log in so that I can access the system.
That, of course, is our base story.
A forgetful user.
I could request a password reminder so I that can log-in even if I forget my password.
Anybody have any other examples?
What else might we write as a story related to logging in?
Anybody think of any examples, you'll have to totally format it into this syntax if you don't want, but any A new user, right?
So we could write a new users story.
As a user I can register on this website so that I have an accountant come back and have it remember things about my usage.
Any others?
Oh, good.
Good.
As a user logging in for the fifth time, I get a discount.
I just did something.
We changed our email marketing system.
Use this thing to send out emails.
And they sent me something because I sent my first email campaign with them.
So I've logged in many times, but I send the first campaign.
They sent something, right?
So, like that one, we get reward to somebody.
Let's get one or two more.
What else do we have?
You're the hacker.
So that's a great example.
That's the great examples.
We're talking about user stories, right?
That is an example of an abuser story.
Right?
Abuser.
Now we don't want to write abusing stories but we want think about them.
All right, we wanna think of them so that we make sure we prevent those things, all right.
And so sometimes it is useful to think things like what does a hacker want, and that can lead us to writing stories like As the chief security officer
of this company, I want all passwords to be eight letters long, minimum eight-letters long non-dictionary words.
Got to include a digit or something like that in there.
Or as a user, i am required to change my password every 90 days.
As a use,r I'm locked out after three failed attempts.
We can write stories like.
And those might originate from the idea of, oh, we got to careful of hackers on here.
The way I like to write stories is in something we call a story writing workshop.
In a storytelling workshop, we bring the whole team together.
Yep, I want the programmers there.
Yep I what the testers there, analysts, designers, database people, scrum master, product owner, bring the whole team together.
Not going to do this every sprint.
My recommendation is to this about every three months.
What I'd like to is set a goal, a target out there on the horizon.
Three months from now we will have this set of functionality done.
We're going move there every two weeks or so.
But I wanna longer term goal.
And we get together and we write stories about where I wanted to be in three month.
Three months later, we write another goal about where we want to be two, three, four months, later.
So we keep setting these kind of goals out there every few months.
We get together, not every sprint, but every three months or so, and we right a bunch of stories about what we wanted done.
What do I want to do on a cruise ship?
I'm going to book a berth on cruise ships.
I wanna be able to see a floor plan so I know if I am close to the pool.
Want to be to request what deck I on.
All those type of things will be part of our cruise-ship stories.
Now when you do a story writing workshop, you need two things to successful.
Two things.
The first thing you need is you a bounding scope.
I always hated that phrase, think outside the box.
That phrase always bugged me and I never knew why.
If I read an article about it a couple years ago, and it was talking about creativity, it said creativity comes from thinking inside the Creativity comes
from thinking inside the box.
I gave you a question a moment ago, I said, hey, help me write user stories for logging in.
Imagine I had yelled out instead, Hey, somebody yell out a user story.
That would have been harder.
Writing a new user's story for anything in the world would've been hard than when I constrained it.
Write a story about this, because that puts your mind into a particular area.
So this article, and I totally agree with this, said that creativity comes from thinking inside of a boundary, inside a box.
So the think outside the box thing is never necessarily was the right way to go.
The first thing you need to be successful is a bounding scope.
Second thing we need be to successful with Story Writing Workshop is some sort of graphical arrangement.
I like doing it in just a simple hierarchy.
There's all sorts of ways to do this.
You can do mind maps, all sort things.
Just going to over the simplest here, a hierarchy, We think about on our travel site, who are our users?
Well, frequent flyers.
They're one type of user.
What are some of the things they want?
Now, I want to do this within our bounding scope.
Now what are the some things that they what?
Those are probably epics.
And then time permitting, we take those and break those down into smaller stories.
So we have to have some sort of graphical arrangement in the story writing workshop.
Otherwise, what happens is you end up with a big pile of cards all over the table and somebody yelling out, did we already write stories for this?
You have no idea.
So something that gives you some presentation of this.
I think stories are a great technique.
I want to talk about why.
Going to end with why here.
One of the things that stories do for us is they shift our focus from writing to talking.
We are not with Agile trying to get away from documentation.
The Agiles Manifesto has this great statement where it says, we value working software over comprehensive documentation,
a lot of people misinterpret that and think, oh, Agil's against documentation Absolutely not.
But on Agile, we are trying to create a shift from documents to discussion.
Write less, talk more.
That's a generalization some projects need to write more to.
but in general, as an industry, We should be talking more, writing a little bit less.
And stories are meant to help us do this.
Now there's this thing, I call it the Grand Myth.
The Grand myth is this, that if we write the requirements down, the user is going to get what they want.
And that's not true.
If we write requirements down, at best, the user is going to get what was written down.
Which may or may not be what they wanted.
My company bought another company a few years ago.
And one of the guys we got as part of that acquisition was an amazing product manager.
I don't want to call him product owner, because he wasn't agile yet.
An amazing project manager, and he had written a wonderful specification document for his team.
So we buy this company, I've got a number of teams there, And I'm going to convert them all to agile over time, but I can't convert all agile day one.
And this one team has a great spec, wonderful specification document.
And it's about a two-month project, so I'm not going to convert them to Agile.
I am just going let them go.
It's an amazing document written by this wonderful product manager.
The product manger is going be busy.
For the next couple of months, I need him traveling around the world, merging our two product lines.
He's the guy who's going figure out what features from which projects are going end up in the consolidated product.
So I will have him travelling around figuring that out.
But it doesn't matter.
They've got a great document, great IEEE, the system shall this, this system, shall that document.
The team starts off on that project, they run it for two months.
The end of two month, the product manager and I are back in their city to see what they've done.
They give us a demo.
they got everything that was in his document.
At the end to that meeting, I remember what he said, because I got up and had to get it out of my head, so I wrote it on the wall,
exactly what it said.
He said you built what I asked for, but it's not what i need.
Now, he owned up to his responsibility for this.
His attitude was essentially, you nailed it.
This is exactly what I had in my document.
What in the world was I thinking?
This was a system for doctors years ago, and he's like, no doctor will ever use this, what was thinking, this is crazy.
No doctor ever touch this?
Now I don't know where we would have figured that out if we had built this project in an agile manner with stories.
Now it took us eight weeks till we got to the end of the project, maybe we could have figure it out after two weeks, but probably not.
Maybe after four weeks.
That's pretty likely.
Maybe, after, four, weeks I'm using twos, because we probably would have done two week sprints.
Certainly after six weeks, I think by then, at a minimum, he would've looked at it and said, wow.
I should probably go show this to some doctors.
This is not looking like something they'd use.
So I don't know where, but probably before the eight weeks we would figure that out.
Stories are going to help us get to the point where we're talking more, writing a little bit less.
We're not quite as reliant on the written word.
One of the reasons I want to be less reliant on the written word is how imprecise words are.
Words are horribly imprcise.
I went to a restaurant in Denver for lunch and this was on their menu.
It said entree or main dish.
Main dish comes with soup or salad and bread.
This is a microbrewery.
They make their own beer there, they've got these big vats of their beer, and they make a really good French onion soup.
And so I wanted the French onions soup with my lunch instead of the salad that day, but I was kind of hungry.
I don't think I'd had breakfast.
So I'm a little bit hungry and I looked at that and said, well, I still want some bread too.
and i wasn't sure how to parse that sentence, right?
Was it soup or salad and bread no matter what, or did you only get the bread if you ordered the Now, I've been to a lot of restaurants,
so I was pretty sure how things worked.
But I'm looking at it, and I realize I am not 100% sure.
And as I look at this, the waitress walks over, puts some bread on the table, And said, can I take your order?
I pretty when I ordered the soup, she wasn't going to take the bread away.
No bread for you.
But there's nothing wrong with that sentence up there, apart from having a French word in it.
But whoops.
Apart from that, there is nothing really wrong that sense.
That sense is perfectly grammatically correct.
Right?
But it's still impossible to know the exact meaning of the sentence.
And I want to show you a couple other examples of words being imprecise.
I've just got a few other slides to share you guys here.
These are both from the same specification document.
And this is actually a really good document, I feel bad for picking on this document because these are probably the only two things in the document I could
pick on.
It was a good really document but this was the bioinformatics system, really hard core medical stuff and there was requirement in there that said the user
can enter a name, it can be 127 characters.
This was a Windows Explorer-like part of the interface.
You were naming folders of genetic data.
So think about Windows explorer.
And it said it can be 127 characters.
I looked at that and I said, well, that's a weird requirement.
Wonder if that is a maximum.
Now most of us will look at and go, of course that a is maximum number.
But this was weird system.
There were requirements on this system where you had to enter names of things that had be 32 characters made up only of letters A,
C, G, and T.
That's a weird requirement, right?
I don't remember enough from my old genetics class, and for me, it would have been high school.
But there's reasons for that to do with DNA and stuff.
It was wacky requirements.
So when I saw this can be 127, I actually had to go ask.
I said, can it be 128? No, no, that's the maximum.
OK, good.
Another requirement on this thing, the system should prominently display an error message.
Should, what does that mean?
Promotively display what that means.
These are all things that we would have to discuss.
A couple other reasons why I think stories are good.
One of the things that is true about stories is they're understandable.
OK, we're in a little session right now.
We're on a one-hour session about Stories.
But we were talking about some of vagaries of them, how to write them and things like that.
we don't have to teach customers how read them.
Customers can read these things.
They'll instantly know what they mean.
As a user, I can book a cabin on the cruise ship.
they'll know that means without any training.
There's a very famous study.
It's called Scripts and Memory for Text.
And what this study did is they dumped a bunch of facts on people, brought a group together like this, just told them a much of fact,
tested them for recall.
They brought another group of individuals together, and they told him some stories.
Embedded in the stories were the same facts.
The tested that group for a recall, which group do you think had better recall?
Second group, stories, right?
I think back, and I remember when I was a little kid, we started school in the US at about five.
I don't remember anything from being five, but I remembered my second year of school.
Remember when was six.
And I can't anything I particularly learned in that class.
If that was the class where I learned how to spell or the alphabet or how add, I dunno what I've learned there.
But I totally, clearly remember sitting in a classroom and the teacher reading us Charlie and The Chocolate Factory before lunch each day.
I remember the stories from that class, but I don't remember anything else.
I mean, I'm sure I remembered how to spell or whatever I learned there, But I didn't have any conscious memories of it.
Stories are memorable.
Now I am not going to say our user stories are as memorable as Charlie and the Chocolate Factory.
It would be nice if they were.
But when we read our stories, they are more likely to stick in our heads I think than little statements, the system shall this,
this system, shall that.
Those just pass right through.
These other things, because they're in first person, we start to relate to them.
have a little bit better recollection of them.
Story support and encourage.
I think that's important.
And encourage iterative development.
This is because of how easy it is to move between a epic, a big story, small story.
Rubber band the small stories back up into a collection of stories called a theme.
Because of how easy it is to move from high level to low level of detail, it makes it easy for us to work on an iterative manner,
to iterate through the project, build a little bit of something at a time.
I was writing the book on user stories a few years ago.
One of the things that blew my mind about stories, I went back, and I had my publisher help me out.
We did some research on what had been the best-selling requirements books of last 20 years, what have been best selling requirements of all time.
And so I read all these old books on requirements planning.
No requirements technique before stories had really come along and ever said, Hey, if it's big, make it smaller, because it is too big for the team to do.
Think about all the stuff you might have learned about traditional requirements gathering.
None of it ever said, hey, it it a big nasty scary hard to-do requirement, you should split it up.
That was never part of that.
So stories were the first requirements technique to come along that were really about a way to document requirements, in a sense,
and plan the project.
And so stories solve two purposes.
They're kind of pointers to requirements, like I said.
But they're also about planning the project.
Serve dual duty.
Very important, I find.
There was a study done at Stanford University in California in 1990, long ago.
It was an interesting study.
The professor who did the study was interested in the question, do we design top down or bottom up?
Top down, or, bottom, up.
Answer to me is kind of obvious, both, right?
But she wanted to solve the problem.
You know, being a researcher, she want proof, not just an opinion of both.
So she brought in elevator designers, and she posed a problem to them.
Your designing the bank of elevators for a building.
The building is this big, it gets this much freight, has this many people working in the building, how many elevates do we need,
which routing algorithm should we use?
And so she videotaped them talking through the problems.
As after she was done, she reviewed the videotapes and documented, were they thinking top down or bottom up?
And she documented where they had breakthroughs, where had epiphanies.
And what she discovered is that we designed, not top-down or, bottom-up, but what was she called, opportunistically.
All right, we design top, down until we get stuck.
Then we go bottom, up for a while, then we top , down, and we bounce back and forth opportunisticly.
Well, stories, again, help us do this because of how good stories are at helping us go between big and small.
Epic down to smaller story, rubber banded back together into theme.
Stories help as go back and forth from high and low levels of detail.
Last real benefit on stories I want to touch on here is that stories support what is called participatory design.
There's two schools of thought on design, the first school of thoughts is what's called empirical design and empirical designs we treat our users like
lab rats.
We bring them into the room.
We watch them through the one-way mirror.
Maybe we record their keystrokes.
we study them, we poke and prod them.
Some of this can be good stuff.
I'm not down on that.
Where we go wrong, though, is that then we, the all-knowing software professionals, make decisions for them We've studied you.
That's where we go wrong.
The other school of thought is called participatory design.
In participative design, we engage the users in the process.
And stories help us do this because of how easy it is for our users to participate in a process, right?
We bring them in, say, hey, write some stories.
I don't train users on how to do this.
I bring them into the room, I write on a whiteboard, as a blank I want blank, so that blank.
And I say, let's fill that bank in.
What do you guys want?
What type of users exist?
what type subpopulations exist in our user community?
We fill in the blanks.
Users become active participants, or can be active participant.
Want to look at one example here.
of kind of an IEEE 830 style requirement.
Is there something up there?
Oh, something went wrong on that slide.
This slide is supposed to have a kind of an IEEE 830-style spec.
I remember enough of it, so I'll ask you to just kind go along with me on this.
Suppose we had a specification that said something like this, we're building a real-world product, not a piece of software,
real world, tangible product.
What I want you think about is, where does your brain go, as I give you a couple requirements?
The product shall have a steel body, the product will have four wheels, The products will a rubber tire mounted to each wheel,
and the products shall a multi-speed transmission.
Where's your head going?
Now you know I'm setting you up for something here, but just go, where are you mentally going with that set of requirements?
Right?
It's the thing we interact with most frequently that fits those things.
Right.
That is a list of system attributes.
The system shall this, the system show that.
Let's see what we would do differently if we had user stories instead.
Keeping in mind that what user's stories focus on is what the user desires of the systems, not the systematic attributes,
so here are a couple of user story.
As a user, I want to mow my lawn quickly and easily.
I want to be comfortable while mowing my lawn.
And so we realize that we're building something completely different.
So the goal here is to focus on the user's goals, not the attributes of the system.
This is something that user stories help us do.
Last thing I'm going to share with you guys.
Don't forget the purpose.
The user story is not a requirement.
So the text we write on the card is less important than the conversations that we have.
excuse me, a pointer to a requirement.
It's a point to do a conversation, it's pointer an Excel document showing me some sample calculations.
There's the pointer a Vizio workflow diagram, something like that.
So the conversation is more important than the card.
The card's point or to that conversation.
I'm going to end there.
I've got classes coming up.
They just told me to announce this.
So I do classes here every couple of months.
Here's my contact information.
And I love talking about this stuff.
But I should have mentioned at the beginning, all the slides from all of the talks I have done today are on my website.
You should go to mountaingoatsoftware.com.
All the presentations are up there, plus over 100 other presentations I'd given over the years.
so you can download all sorts of stuff from up here.
Thank you guys very much.
