Transcript
Hi, and thank you for signing up to this free training on user stories.
I'm Mike Cohn from Mountain Goat Software.
This is just one in a series of free videos that will help you overcome some of the biggest problems with user story.
You can follow the links on this page to watch the other videos.
As lightweight placeholders for conversations, user stories encourage communication.
They help you plan and prioritize what to build, all while keeping the focus on end user value, which in turn delivers value to your customers.
User stories eliminate lengthy documentation and tedious meetings, Which keeps your teams engaged and improves momentum and motivation.
There's just one problem.
Despite their inherent value and simplicity, user stories are far from easy to master.
For too many agile teams, writing user story is a constant struggle.
But it doesn't have to be that way.
I've coached more than 20,000 people on user Stories.
And I want you to know that writing great stories is easier than you might think.
I've seen people with all levels of experience, various roles, and different backgrounds transform their approach for the better.
So I know I can help you.
There are three main challenges that overwhelm teams today.
These are getting teams engaged enough to write user stories, adding too much or too little detail, leading to delays in development and missing functionality,
spending too time trying to split stories in a meaningful way at the cost of building something.
I've created a series of videos with behind the scenes training that shows you how to solve common problems around each of these challenges.
I'll also let you know about a resource you can use to truly master user stories for good.
Keep watching to find out more about that.
In this first video, I'm going to show you how to make sure you start on the right track.
I will show how you reduce resistance and get your team engaged when writing user story.
And I show more meaningful discussions.
Discussions that zero in on a user's needs from the very start.
One viewer said this video really helped his team see the big picture and organize thoughts while creating user stories.
Another said it helped uncover missing stories and resolve prioritization issues.
I'm confident you'll find it valuable also.
After this video, you're going to know how far ahead to look when writing user stories.
Who should write user's stories?
Should it be one person, the entire team, or something in between?
How to do story mapping to uncover functionality you may have otherwise overlooked.
To do this, I'll show you how to focus your storywriting sessions so that story writing doesn't become a never-ending process.
In short, this video is going to give you a great start to writing user stories.
But before we jump into the how, i want to share two stories that show why even smart agile teams can find themselves with user story issues right from
the start.
When I first met Sharma, he was really down.
He was an analyst for his team, and his product owner had asked him to write the product backlog for a new product.
Sharna wrote the user stories covering what he thought would be the first few months of work on the project.
And when he shared them with his teams, I think he expected a Pulitzer Prize for the job he'd done crafting all those user-stories.
Instead, Sharma's team peppered him with questions.
What should we do if the user's account is expired?
How should handle it when this rare thing happens?
Wouldn't users prefer to do this story after having done that other story?
Can all users do or just some?
Why do users want to this at all?
The questions went on and on.
Sharmas team had so many questions because what they were being asked to build was completely new to them.
They wanted the answers.
but they were also trying to understand the product and buy into the vision.
Remember, they had not participated when the stories were initially created.
Sharma had done that alone.
So although ultimately Sharama was able to communicate his vision for the project, he spent far more time doing so than if he'd simply involved the team
in writing stories from the start.
Co-creating something, it turns out, is one of the best ways of establishing an aligned vision of a product.
Rick and his team suffered from a different problem.
Rick was a product owner and unlike Sharma, he did include his time in writing user stories, but Rick overdid it.
He held three solid days of story writing meetings in an attempt to document every user story that would be built over the coming year of development.
Rich told me he was later frustrated because even with so much time invested, his had failed to identify all of the needed user-stories.
When that product was deployed 12 months later, users were unimpressed.
They'd waited over a year and some critical functionality was missing.
If Rick and his team had spent less time trying to predict every user need upfront and more time engaging actual users in multiple story writing sessions
spread across the year, they would have been much more likely to have discovered that overlooked functionality.
The situation was so frustrating for Rick that he left the company shortly after this.
I met him at his new company when he brought me in to facilitate a storywriting workshop because he wanted to understand what had gone wrong at this prior company.
Both Rick and Sharma had, unfortunately, started their projects off on the wrong foot.
Sharna, by not doing a storytelling workshop at all, and Rick, thinking that one story writing workshop could discover all functionality for a year-long project.
Stories are not simply a replacement for a traditional requirement specification.
We don't tear up the big document full of the system shall this and the systems shall that and replace it with an equally long document,
full as user I want this, and as a user, I went that.
I coached Sharma and Rick to engage their teams in a lightweight approach to identifying what their team's needed to build.
Sharman needed to include his developers in this, and Rick needed hold regular, shorter workshops.
Fortunately, these problems can be easily avoided by properly conducting your storywriting sessions.
So in the lesson, I want to share with you three tips for conducting a successful story writing workshop.
The first tip, and one of the most fundamental things you can do if you want to run a storywriting workshop successfully,
is to focus the meeting on a single, significant objective.
Your significant objectives should be something that will take a couple of months to do.
That means it's bigger than a simple iteration.
And the best news about that is that it means you don't need to a do a storytelling workshop every iteration, in fact, doing so is a bad idea.
The team's product owner, key stakeholder, or whatever you call their primary visionary for the product should select a single big goal and bring it as
input into the story writing workshop.
Some product owners have full authority and can simply determine the significant objective on their own.
This would likely be the case in a small startup.
The founder decides what general functionality needs to be developed in the coming quarter and that's it.
In most cases though, a good product owner will identify the significant objective in collaboration with stakeholders.
The product will talk to customers, users, and others in company about what they think is the most important thing to focus on in next three months.
If your team uses the term minimum viable product or MVP, developing an MVP could be a great significant objective.
An MVP is valuable.
Your users will either like it or you'll learn from it more about what users really do want.
And an MVP is significant in that it will probably take longer than a single iteration.
This doesn't mean a story writing workshop is something you should only do when working to build the first minimally viable version of your product.
No, a story writing workshop is just as valuable for ongoing development.
In fact, the term I like better than minimum viable product is minimum marketable feature, or MMF.
This comes from the book Software by Numbers.
It refers to a chunk of functionality that delivers a subset of what users need.
but that is enough to be valuable to users when released.
So a team's significant objective could be an MVP in the early days of a product when trying to determine what their product should be,
or it could a minimum marketable feature once viability has been established and their project is being incrementally improved or enhanced.
Whichever way you choose to think about it, though, you really want to start a storywriting workshop with a significant objective that will take a few
iterations to achieve.
I recommend the cadence of a quarterly cycle, so you want a significantly objective, that can be delivered in about that amount of time.
The significant objective is an input into a successful storywriting workshop.
The workshop starts with the product owner or key stakeholder presenting the significant Objective.
But besides the Product Owner or Key Stakeholder, who participates in this meeting?
That's the second tip I want to share with you today.
For a Successful Storywriting Workshop, you need to have the right participants.
Of course, the Project Owner and Key stakeholder needs to participate.
If you're a Scrum team, the Scum Master should be there.
If your doing something other than Sc rum and have a coach, that person should attend.
Your Scrum master or coach will facilitate the meeting.
They'll do things like keep an eye on whether everyone is staying engaged or if perhaps it's time for a break.
The facilitator will do anything they can to make the meetings run smoothly and productively.
You should also have the development team members participate.
That means programmers, testers, analysts, designers, database developers, technical writers, and so on.
Anyone involved in the developing of their product or system should be there.
You may be tempted to leave out some or even all of the Development Team members.
I strongly advise against that.
Having the whole team in this meeting will lead to them being better engaged later.
Also, when stories are developed, team members are going to have questions about how some stories should work, what is meant by a given story,
and so on.
If they participate when the stories were first written, they'll know the answers to more of those questions during future iteration planning sessions
and during the iterations themselves.
So, having team member participate is not as time-consuming as it seems, as the project will save some of this time later.
Finally, having team members participate will likely lead to more creativity during the meeting.
Team members bring a different perspective from the other participants, and this can often result in more innovative solutions.
Let me give you one possible exception to involving the entire team.
If the significant objective that will be discussed involves multiple teams, that would lead to a lot of people participating.
In this case, I'd be okay with a subset of the development team participating, select people based on who will contribute the most to the workshop and
who is most willing to participate.
As an alternative though, you may want to consider parsing the significant objective up into parts by team.
Each team then takes complete responsibility for achieving a part of the overall significant objectives.
If you do that, You would have multiple smaller story writing workshops and each would be attended by a full development team Okay,
so I've said that participants in a story writing workshop are the product owner or key stakeholder, the scrum master or coach,
and the development team.
What about users and stakeholders?
Yes, normally you should include them, or at least invite them.
But there are times when you may not want to.
Sometimes stakeholders can be very disruptive as they argue among themselves over whose pet feature is more important.
If you run into this problem, you'll want to emphasize to stakeholders that a storywriting workshop is about understanding what users do or will do with
a product.
Just because something is discussed during the workshop does not mean it's going to be prioritized over some other feature.
If your really clear this up, it can stop a lot of that arguing and posturing that some stakeholders will in a storytelling workshop.
So if at all possible, include stakeholders and users.
That brings us to the third tip for your story writing workshops, and that is to use some way to graphically visualize the relationships between stories
while they're being written.
There are a few ways to do this, such as a goal story hierarchy or a mind map, but I want to talk today about using a story map because in most situations,
that will be the best way to visualize stories.
A story is a two-dimensional representation of the things a user wants to.
The first dimension is the sequence of activities that is depicted horizontally across the map.
For example, let's suppose you're on a team that has been told to develop software that will allow company employees to submit expense reports and be reimbursed.
To create a story map, we begin by documenting each step in the process.
The first thing an employee who wants to submitted an expense report needs to do is log into the new system you'll develop.
So we start the storymap by writing log in on sticky note or index card.
Next, our user is somehow going to tell the system that he or she wants to start a new blank expense report.
After that, the user enters the expenses.
Dinner on Tuesday costs this much, a night in a hotel costs that much and so on.
Then, after all the expense has been entered, The employee submits the Expense Report for approval.
The way we read this story map is quite natural.
We read across by mentally inserting the word then between each of the cards.
So this StoryMap reads as log in, then start new blank expense report, Then enter expenses, THEN submit for approval.
But I said a Story Map is two-dimensional.
we've only got one dimension here.
so what's the second dimension?
Vertically on the story map, we can list alternatives.
For example, looking at our story, map we might realize that some users could create a new expense report by copying an old one.
I do this quite often.
When I need to create an expense for something I've done before, say a trip to a particular city, I start by making a copy of the prior expense.
Report I often stay at the same hotel and eat at same places, so this saves time.
So let's add an additional item to our StoryMap, Copy an Existing Expense Report.
You can see here that I put that item below Start New Expence Report, since it represents an option the user has at this point in the sequence.
This means the second dimension on a Story Map is vertical, and we read that by mentally inserting OR between the items.
So this part of the Story map is read as Start new blank expense report or Copy and existing expense reports.
Sometimes, when you show alternatives, you can make the story map more clear by adding an additional card that summarizes what the alternatives do.
I'll do that here.
Above the two cards that show alternative for how a user might start an expense report, I will add a new card titled Start New Expense Report.
This is all good so far, but let's look at two ways in which Story Maps become very helpful.
First, Story maps can help you find stories or functionality you may have overlooked.
To do this, walk through the Story Map and see if anything is missing.
When doing this it can be very help to ask a few questions at each step such as, what will a user most likely want to do next?
What mistakes could a use make here?
What could confuse a user at this point?
What additional information could a users need?
If your product has multiple types of users, ask these questions for each type of user.
Doing this on our sample story map, I realized that users are often going to need to attach receipts for some expenses.
So let's add that as a new step.
And maybe participants in the story writing workshop suggest that the product allow users to do this two ways.
First, they suggest it would be nice if the system itself could activate a device's camera and scan a receipt directly.
Second, users will need an ability to attach an existing PDF or image to the receipt.
And you can see I've added each of these alternatives below the Attach Receipts card on the Story Map.
But when we add alternatives to a Story map, we should add them in priority order.
High priority items should be higher on that map.
So I'm going to swap the order of the two newest cards.
I think it's going be much more important to attached existing pdfs or images than it will be to have the system scan receipts itself.
That seems much more like a nice-to-have feature, so I've positioned it lowest on the story map.
Because story maps are arranged vertically from high priority down to low, that gives us the second big benefit of story mapping.
We can use the story map to select the stories that will be delivered in different releases of a product.
To do this, we add a horizontal line to the map and then drag above the line everything that must be included in the next release or version of the product
for our mythical expense reporting system.
we need the ability to log in.
We also need to start a new expense report, but let's assume that starting with a New Blank Report is good enough at first.
We'll add the ability to copy an existing expense reports later.
Users will need be able to enter expenses, and they'll need attach receipts.
But initially, attaching existing PDFs or images will be good.
So we'll leave the story about scanning below the line.
And users will to be to able submit the finished expense for approval.
If you need to, you can go further with this by adding additional lines to represent subsequent milestones, and then positioning the necessary stories
above each milestone line as appropriate.
If do this, it's also nice to put a label above the each line that describes what that milestone or release of the product represents,
as you see I've done here.
This is a great way of visually conveying a roadmap of planned future functionality.
So to recap, for a successful story writing workshop, you want to make sure you focus on the right objective, have the people there,
and visualize the relationships between stories with a technique like story mapping to help you and your team prioritize needs in a way that drives business value.
If you follow this advice, you'll be off to a great start.
But once you have your user stories written, your going to need to know how to split them.
If your don't know to how split user story in a meaningful way, Your going run into some problems pretty quickly and others much further down the line.
In the next video in this series, You're going hear how one team decided to give up splitting stories all together and discovered some unexpected consequences
from that.
What's more, I'll be sharing a simple five-step technique that streamlines and simplifies splitting stories, even complex ones,
without compromising quality.
This means you can save a lot of time when it comes to splitting the stories and have stories that deliver stakeholder value and can be completed within
an iteration.
The technique I'll share with you can really take the pain out of the process of splitting user stories.
You can find details about how to access that video on this page.
I'd love to know, what is the one key lesson you learned today that you found most valuable?
Let me and everyone else know by writing it in the comments.
If you've enjoyed this video, I want to let you know about an additional resource to take your learning even further.
On this page, you'll find information about becoming a member of the Better User Stories course.
Better user stories is an in-depth video course covering all aspects of user Stories.
It's based on practical materials I've used for teaching the subject to more than 20,000 people over the last 15 years.
Ken Rubin, the author of the bestselling book, Essential Scrum, was even kind enough to tell me that he recommends better user stories to his clients as
a way to improve their personnel's user story writing skills.
To find out more about the course, simply follow the link on this page.
