Use cases vs user stories in Agile development

TL;DR – User stories aren’t use cases. By themselves, user stories don’t provide the details the team needs to do their work. The Scrum process enables this detail to emerge organically, (largely) removing the need to write use cases.

Are user stories the same as use cases?

When running our Writing Great Agile User Stories workshop, I’m frequently asked “So – are user stories the same as use cases?”. Often it’s a business analyst who asks the question; they’re accustomed to working with use cases, and are wondering where use cases fit in a Scrum project, and if they’re replaced by a user story.

Looking around the web, there’s consensus that use cases and user stories are not interchangeable:

My standard answer is that user stories are centred on the result and the benefit of the thing you’re describing, whereas use cases are more granular, and describe how your system will act. And then I say “Just bear me – it will all be clear in soon”. But I thought it was time to dig further down into this.

Use cases and user stories

Let’s start with some definitions.

A user story is a short description of something that your customer will do when they come to your website or use your application/software,  focused on the value or result they get from doing this thing. They are written from the point of view of a person using your website or application, and written in the language that your customers would use. A user story is usually written using the format canonised by Mike Cohn: As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos.

A use case is a description of a set of interactions between a system and and one or more actors (where ‘actor’ can be people, or other systems: for example, both online shoppers and PayPal can be actors). They are usually created as documents, and generally include this kind of information:

  • Use case title
  • Rationale/description/goal
  • Actor/user
  • Preconditions (the things that must have already happened in the system)
  • Standard path or Main success scenario (what will usually happen, described as a series of steps)
  • Alternate paths or Extensions(variations on the above/edge cases)
  • Post conditions (what the system will have done by the end of the steps).

At first blush, use cases look like a much better way of writing requirements than user stories. How will a team be able to implement something as wafty as As an [actor] I want [action] so that [achievement]. So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos without some rigorous use cases to detail the requirements for the system? And that’s usually the point when someone in the workshop asks that question.

Writing use cases to flesh out user stories in Agile projects is certainly not unheard of (see here, and here). But it becomes clear as we move through the workshop that user stories are just the start of a process of understanding what the team is making that, by the end of its course, covers off everything a use case would have told you, but in an organic manner.

Acceptance criteria

User stories aren’t just single sentence affairs. The product owner also writes acceptance criteria, which define the boundaries of a user story, and are used to confirm when a story is completed and working as intended. For example, if this is your user story: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork, the acceptance criteria could include:

  1. A user cannot submit a form without completing all the mandatory fields
  2. Information from the form is stored in the registrations database
  3. Protection against spam is working
  4. Payment can be made via credit card
  5. An acknowledgment email is sent to the user after submitting the form.

Writing the acceptance criteria is the first step of fleshing out the details of your user story

Sprint planning meetings

In the sprint planning meeting, the product owner presents the user stories from the top of their product backlog (ie. their highest priority features) and the team commits to the stories they will complete in the sprint.

As the product owner presents the stories, the team will ask questions to further clarify the user story and the acceptance criteria. Assumptions will quickly be confirmed or corrected, and any ambiguity about the requirements starts to disappear.

This assumption and ambiguity erasure continues as the team estimates the stories (if five people on the team rates a story as a 2, and one person rates it as a 5, there’s probably some questions that need answering). And it’s repeated again as the team writes the individual tasks for each story.

Standups

We’ve been fortunate in our Scrum projects, in that our product owners generally commit to attend the team stand-up. This is another chance for the team to ask questions, and also to make the product owner aware of restrictions, issues and opportunities are appearing as the story progresses.

Wireframing

I do the wireframing for some of our projects, and usually I start by talking to the product owner about the story, and sometimes making some paper or whiteboard sketches. I turn these into wireframes and then there’s normally a couple of quick iterations with the product owner as we ask each other questions, get feedback from other people, and hopefully squeeze in some user testing.

More recently, I’ve started reviewing the draft wireframes with the designers and developers working on the story. This helps flag up any questions they have, or restrictions I might not have been aware of. After the wireframes are approved by the product owner, I’ll brief the designers and developers again if needed.

Design and development

Although most of the details have been thrashed out during the wireframing more can crop up at this stage, and there are often more questions for the product owner about exactly how they want the backend of the system to behave. Pair programming is useful here, because two sets of eyes on a piece of functionality mean yet more questions and clarifications.

No user story is submitted for acceptance by the product owner until the acceptance criteria are satisfied and the definition of done is met.

Overall

This might sound like a lengthy process. In reality, it’s just what a Scrum team does all day. Rather than one person labouring over the use cases, the team works together to surface and satisfy all the requirements. The product owner can refine the original acceptance criteria in response to new information throughout a user story’s progress.

And finally, in conclusion

There are exceptions, of course – and there are times when the upfront research needed for use cases is important (I’ve got a blog post brewing on this). But my advice would be: don’t start writing use cases until your team specifically asks for them. And if your team does ask for them, spend some time in a retrospective digging into what they’re not getting from your current processes (for example – are the acceptance criteria unclear; is the product owner  unavailable; are you working with shitty documentation for another system). Then decide as a team how to fix the root problem.

Further reading

Advantages of user stories for requirements – Mike Cohn

Requirements 101: User stories vs use cases – Andrew Stellman

The 2011 Scrum Guide – a quick review

Here at Boost we’ve been reviewing the updated Scrum Guide by Jeff Sutherland and Ken Schwaber, released in July (you can download the guide at Scrum.org)

Rather than covering techniques (like release planning, burndowns and sprint tasks) the guide focuses on what makes Scrum Scrum: the roles, events and artifacts, and the set of rules that bind these together.

In an introduction to the changes from the 2010 Scrum Guide, Schwaber and Sutherland compare the Scrum Guide to guides for games: rules (pass go, collect $200) are different from strategy (get to three houses as quickly as possible, because this is when the rent bumps up dramatically). They write:

The Scrum Guide is the definitive rule book of Scrum and the documentation of Scrum itself. The Scrum Guide and the rules of chess offer simply the rules on how the pieces move, how turns are taken, what is a win, and so on.

Strategies for playing Scrum or chess vary widely and are explained in many books, articles, and blog posts on the respective subjects. For those of us working on a revision to the Scrum Guide, this meant that all tips, optional practices, and techniques should be removed from this document. This was done along with refining some language to correct some long-standing misunderstandings about Scrum.

Given the Introduction to Scrum workshops we’re running at the moment, we were keen to look at the Guide in terms of how it can help us teach people about Scrum. Here are some of the passages that really grabbed us:

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

We often explain that a key part of the Scrum Master’s role is to clear impediments that are stopping the team from working as well as they could. Here, we like the notion that the Scrum Master isn’t just clearing blocks, they’re teaching people to proactively stop the blocks from happening.

… each event in Scrum is an opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

We’re frequently asked whether all the events in Scrum (stand-ups, planning meetings, task estimation, demonstrations, retrospectives) are really necessary. We usually say that of course you should use the structure and methods that suit you best – but that if you’re not following the Scrum events, you’re not using Scrum.

We also try to explain how you can go through the motions of Scrum events without getting the benefits. Thinking of every event as an opportunity to inspect and adapt, and to create transparency, reminds you of why these events are held and the spirit in which people need to participate.

A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, a Product Backlog also exists.

The Scrum Guide’s section on the product backlog  really emphasises that the product backlog isn’t there just to get you to an initial release – it is a long term commitment. In fact, the Guide states that the product backlog will become ‘larger and more exhaustive’ after launch. Interestingly, the Guide also dwells on the role of team members in contributing to product backlog grooming, not just the product owner and stakeholders/subject experts.

Overall, the 2011 Scrum Guide is concise (a slim 16 pages), focused and a useful resource for newbies and experienced Scrum practitioners alike. Enjoy!

More reviews of the differences between the 2011 Scrum Guide and earlier versions:

Scrum in 10 Minutes

One of the topics we most frequently talk about here on the Boost blog is Scrum and Agile development.

Much of the information is targeted at people who are already familiar with Scrum and Agile, but we are well aware there are many people out there to whom Scrum is something to do with rugby, and being Agile is to do with being flexible (which I suppose is actually true either way).

As a relative newcomer to the worlds of Agile and Scrum, I’m realise there is quite a learning curve, and throughout my learning process I’ve come across a number of different resources that have helped my understanding immensely.

One of the more useful resources I have come across is the following video (and of course, the great free ‘Introduction to Scrum’ seminar we run here at Boost), which quite succinctly explains Scrum in less than 10 minutes.

Of course, there is more to Scrum than this, and a number of different ideas and terms that you’ll have to remember and understand, but it’s a great way to get started.

Scrum in 10 Minutes

 

Did you catch all of that? There is a lot of information being covered in a short period of time, and I’d recommend watching the video a couple of times to try and listen and understand all the information that is being shared.

A couple of our Scrum Masters here do have a couple of thoughts to add to the video though:

  • Scrum Masters and Projects managers aren’t the same thing
  • We like to user story points for estimation as opposed to hours
  • We do a burn-down of hours and a burn-up of story points
  • We think daily stand-ups are essential, regardless of team experience

Of course you are more than welcome to ask any questions you have about the video in the comment section below, or ask us on Twitter @BoostNewMedia or on our Facebook page. We’ve also included some of the key terms from the video below to help with your learning.

Key Scrum Terms

 
There are a few key terms in there that are pretty crucial to understanding Scrum, and for your benefit (and mine), here is a quick recap of some key Scrum terms using definitions from the video. Feel free to chime in with your own definitions if you have something to add:

Product Backlog: A wishlist of features you’d like to implement for your site/service/product, generally ordered in terms of business value.

Product Owner: Represents the users and owners of the site/service/product to ensure the right features make it through to the Product Backlog. They set the direction of the site/service/product.

Scrum Master: Makes sure the project is progressing smoothly, and that every team member has the tools they need to get the job done. They also remove any impediments to progress for the team.

The Team: A multifaceted group that gets the job done; includes developers, testers, and other talents as required.

Sprint: A short duration milestone that gets elements of a site/service/product to a ship ready state, taking prioritised tasks from the Product Backlog.

Burndown Chart: A chart that shows a day by day measure of the amount of work remaining in each sprint or release. Often has a Burndown Velocity line showing the trend of the project to help you understand if the project is going to be finished, early, on time or later than expected.

The Daily Scrum: A daily stand-up meeting (aka. The daily stand-up) with the team that asks ‘What did you get done yesterday?’, ‘What will you work on today?’ and ‘Are there any obstacles in your way?’.

Further Resources

That’s a wrap

Simple, huh? Of course, that’s a very introductory overview, but hopefully this video makes you realise that it’s not impossible to learn, and shows you a few of the ways that Scrum can improve your development practices.

If you’ve got any questions about Scrum, let us know in the comments below, and we’ll do our best to help you. Don’t forget to subscribe to our RSS feed to keep up with our latest news and adventures, and to help you continue on your Scrum learning way.

Thanks for dropping by.

Agile experiments: creating user stories with story mapping and ‘buy a feature’ prioritisation

Here at Boost we’ve been running Agile projects (using Scrum) internally for about five years, and with clients for more than three. Constant refinement and improvement is a key aspect of Scrum processes, and for our scrum masters in particular (myself, Gavin, Kriston and Courtney) looking for ways to tweak our projects is a big part of what we do.

One way we do this is by trying practice runs of new processes internally before we unleash them on our clients. Recently we trialled story mapping as a different way to generate user stories, and then tested two different ways of prioritising the stories into a product backlog. We learned a lot from this, and are looking forward to trying it with clients soon.

What is story mapping?

Jeff Patton has done the most to formulate the method of story mapping, and he contrasts it to the traditional ‘flat’ product backlog. Patton argues that while a flat product backlog is good for helping the team understand what needs to be done next, it doesn’t help the team see the big picture of what they’re making:

Arranging user stories in the order you’ll build them doesn’t help me explain to others what the system does. Try handing your user story backlog to your stakeholders or users when they ask you the question “what does the system you’re building do?”

For my money, trying to understand the system – the whole system – is the difficult part of software development. One of the most common complaints I hear from Agile teams is that they lose the big picture – that is if they ever had it in the first place.

… [A] story map arranges user stories into a useful model to help understand the functionality of the system, identify holes and omissions in your backlog, and effectively plan holistic releases that delivery value to users and business with each release.

Occasionally on our Agile projects we’ve run into the problem where, although we’re working in order of priority and regularly delivering new functionality, it still feels like that new functionality isn’t building into a cohesive whole for users. We decided to try out story mapping to see if it might help in these situations.

Generating the stories

For the trial we had:

  • the four scrum masters (me, Kriston, Gavin & Courtney)
  • a big empty wall
  • some builders tape, lots of Post It notes, and a bunch of Sharpies

I facilitated the story mapping, and Kriston, Gavin and Courtney took on the role of the team. Gavin was our Product Owner, and Kriston & Courtney played the part of topic specialists, there to advise the Product Owner on business and user needs. (Any combination of people could form the team for this exercise, but it’s important to make sure that the Product Owner continues to be the person making decisions about priorities based on business value, with everyone else there to advise and support them.)

The scenario we used was imagining we were going to launch an online card-sorting tool to complement IntuitionHQ, our online usability testing tool.

First, I asked the Product Owner ‘What will people do with this tool?’ (this is a more user-focused way of asking ‘What will our software do?’). The team brainstormed the high-level activities:

  • manage the site (admin features)
  • open and manage an account
  • create and distribute a test
  • display results

The Product Owner wrote each of these down on Post Its and and placed them in a row above a strip of builder’s tape on the wall.

Next I got the Product Owner to brainstorm the user stories that fell out of each activity, and stick them up in columns under the related activities. For example, under ‘Open and manage an account’, we had the user story As a IntuitionHQ customer, I want to log into the cardsorting tool with my existing account details, so I can get started testing quickly. We ended up with about 25 user stories across the four columns.

'Wall' with stories arranged into groups

'Wall' with stories arranged into groups

Prioritisation 1: traditional method

At this point, the user stories were in random order in their columns. Next I got the Product Owner to order them from most to least important within their columns.

After the stories were prioritised, I got the team to work together to identify a ‘walking skeleton': the stories from each column we’d have to complete in order to have a first release of the software that was both high value and immediately useful. We put a line of builder’s tape across each column where the cut-off point fell.

'Wall' with priortised stories

'Wall' with priortised stories

Prioritisation 2: ‘buy a feature’ method

Next we tried another way of selecting stories for the first release. We went through and roughly sized each of the stories, allocating 1, 2, 3, 5, or 8 points to each (in the real situation, we’d have the people working on the project estimating like they normally would).

Then I gave the Product Owner a ‘budget’ of $30 to ‘buy’ the stories they wanted to see in the first release (with ‘buy a feature’ prioritisation, you use a budget of between 1/3 and 1/2 the entire system budget, to force decision-making.) The ‘cash’ was in the form of small Post Its with $5, $2 and $1 written on them – so to buy an 8 point story, the team had to pony up a $5, a $2 and a $1.

'Wall' with stories prioritised by 'buying' features

'Wall' with stories prioritised by 'buying' features

What we learned

It was fascinating watching the team change their mind about priorities with this spending limit in place. For example, in the first prioritisation, the story As a IntuitionHQ customer, I want to log into the cardsorting tool with my existing account details, so I can get started testing quickly didn’t make the cut as a first release. In terms of opening and managing an account, this was originally seen as a nice to have, compared to the functionality to create a new account. When faced with a limited budget however, the team decided this was the only story they wanted to buy from the ‘Open and manage an account’ column, reasoning that for a beta release, they’d be happy to offer the site just to existing customers. This released more cash to buy the essential stories associated with creating and distributing tests, and collecting and displaying results.

Based on current and previous projects, we know that a point usually represents about three hours work. Using this technique of estimating and ‘buying’ stories, we know we’d be able to give a client a reasonably accurate picture of what we’d be able to deliver within any given budget.

Where we think story mapping will be useful

The scenario we picked – building an online card-sorting tool – was quite simple, and as we’ve built something similar we had a good understanding of what we’d need and how much work was involved. Our story mapping exercise was therefore quite straightforward, and we completed it in under two hours. In his article ‘How you slice it’ (download the PDF) Jeff Patton describes how to run a far more complex story mapping exercise. The overall goal remains the same: a useful and highly usable first release, which sets the stage for further iterations. As Patton writes in the article:

Incremental release may be one of the more valuable aspects of the various Agile development methodologies. An early release can help capture market share, generate early return on investment, and reduce money risked on software development. A strong early release can increase those benefits immensely. The model we’ve built can give you a better picture of your software’s features and help your organisation construct the most useful and coherent early release possible.

We can see a number of situations where this technique will be useful

  • at the beginning of any Agile project, when user stories need to be written and prioritised
  • particularly, at the beginning of projects where the software or product is intended to do a number of different things
  • when you’re working with a team that has previously felt like it doesn’t have the big picture of a project
  • when a product owner is finding it hard to prioritise stories for the first sprint or first release
  • when a product owner needs support getting stakeholder agreement on how features and stories are to be prioritised.

More background on user stories

Want to know more? Check out our introductory series

Don’t forget to subscribe to our RSS feed to keep up with all our latest news and developments, as well as a ton of great Scrum and Agile resources. Thanks for dropping by!

User stories and stakeholders – bringing people on board with Agile

Welcome back!

So far in this series I’ve covered

Today’s post is about how you can use user stories (and other tactics) to engage stakeholders in an Agile project.

It might sounds like user stories are being proposed here as some kind of magic bullet for any and all project woes. They’re not. User stories are a tool, and like any other tool, if they’re badly used or ill supported they won’t bring you the benefits you were seeking. Equally, when well used they not only underpin a very effective development process but can also be used to communicate project progress and decision points to people outside the development team (aka stakeholders).

What’s a stakeholder?

As noted in the post about the development process, in an Agile project there are three roles: Product Owner, Scrum Master and team member. Only people doing actual work are in the team. Only people who are in the team go to stand-ups, retrospectives and planning sessions. It might sound blunt, but that’s the way it works best.

I usually define ‘stakeholder’ as a person outside the team who has a direct interest in the project’s outcome. (This is another good definition.) They might be paying for the project, they might be ‘sponsoring’ the project within an organisation, they might be the people who work with the end customers. They are the people who the Product Owner needs to take direction from and report back to.

Product Owners and stakeholders

The relationship between the Product Owner and project stakeholders can be a delicate dance. Ideally, the Product Owner will be someone who the stakeholders really trust. The Product Owner is constantly making decisions for the project, and needs to have the confidence to make these without referring back to the stakeholders in each instance. Equally, the Product Owner needs to keep stakeholders advised of progress, and get sign off on any necessary decisions.

I’ve been the partner in these dances before, and I’ve learned it’s something you get better at the more you practice. Here are a few things that I’ve found work well.

Kick-off meetings

Before you start writing user stories or anything else, bring the whole team and all the stakeholders together. Get the stakeholders talking about who their customers are, and what they want to make for them.

In these meetings, we often use a variation on the project success slider tool to understand the environment we’re working in. Often stakeholders are under pressure: a limited budget, a tight timeframe, a group of customers who they need to deliver a new service to.

Project Success Slider from LibraryTechNZ

At Boost we used a modified version of the sliders, where each factor can be awarded a value between 1 and 7, but only 28 ‘points’ are available to be awarded. We find the exercise has two benefits:

  1. Everything gets discussed out in the open, and the group has an objective and visual way of reaching consensus on what the project needs to do in order to be successful (e.g. “We’ll accept delivering beta software that’s 80% in terms of our quality criteria, if it means that we hit our deadline and we have all the functionality we wanted to get out there.”)
  2. An understanding is reached that can be used to make decisions later in the project. Say the group decided that staying within budget was more important than the timeline. Now imagine a scenario where a key team member has to take two weeks’ sick leave a month before launch. Going back to the original values, you decide to push out the launch and wait for the team member to come back to work. If you’d decided timeline was more important than budget, you might decide to bring in a contractor to take the team member’s place to get the work done in time for the scheduled launch.

Priorities and the product backlog

I don’t advise getting stakeholders involved in writing user stories, or doing the prioritising. However, they are likely to want – and warrant – insight into what’s being prioritised and why. And you as product owner need to make sure you’re still making decisions according to the business’s needs (and that the business needs haven’t been changed without anyone telling you).

A technique that’s worked well for me in the past looks something like this. The afternoon before the sprint retrospective, but after I’ve prioritised the user stories for the coming sprint, I have a meeting with the project stakeholders/sponsors. I show them the work that’s been completed since we last met, and present anything that needs to be signed off as a milestone. I explain what I’m trying to achieve in the next sprint. Then I confirm that my priorities are still the right priorities.

I usually use Pivotal Tracker and show stakeholders a view where completed stories are presented in one column, current sprint stories in the next column, and the unstarted stories in the last column. It’s a project update in one screen. Then if they chose to reprioritise anything, they watch on the screen as I drag and drop stories around. It demonstrates very effectively the impact of these decisions on when work is likely to get done.

Demonstrating progress

Because the focus with Agile is on regularly delivering deployable software, you’re in the happy position of frequently showing stakeholders completed chunks of work. And because user stories are written in plain language, when you look at a list of completed stories it’s easy to understand exactly which features and functionality have been completed – even if you’re delivering something hard to demonstrate, like setting up a server or fixing bugs.

Between demonstrations and the user stories, I’ve found there’s rarely any need to write project update documents. It’s obvious what’s been completed, and what remains to be done. It’s also possible to see if you’re working more slowly than you expected, and therefore need to start thinking about getting more people into the team, or freeing up more of existing team members’ time for the project.

In summary

The things you’re already doing as part of an Agile project make good communication tools when you’re talking to people outside the project. You can do reporting without the overhead involved in writing reports, and you can stay within the spirit of the process. All of this helps develop people’s understanding of how web and software projects happen.

That’s all for this week. The next post will look at trouble-shooting some of the common challenges faced on Agile projects. Thanks for reading!

User stories in action – the Agile development process

Welcome back! So far in this mini-series I’ve covered the basics of user stories, and added some detail in the shape of acceptance criteria. Today’s post is about the INVEST model for writing user stories, but for that to make sense you need to know how an Agile project is run.

If you’re already familiar with Agile development, you might like to skip down the page to the section about the INVEST model. Otherwise, go make yourself a cup of tea and then settle in for a description of the Agile development process from the Product Owner’s point of view.

Agile / Scrum

Scrum is the form of Agile development that I’m most experienced with, and the one we follow here at Boost.

In Scrum, the development of your product (a website, a piece of software, an application) is split into a series of iterations, called sprints, each of which is usually between 2 and 4 weeks long. The number of sprints in your project might be determined by budget (how many staff, for how long, can we afford to put on this project?), time (how long until we need to have something live?) or experience (how long has this kind of project taken us in the past?).

At the centre of an Agile project is the team. As Mike Cohn writes:

Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. The team is cross-functional so that everyone necessary to take a feature from idea to implementation is involved. These teams are supported by two specific individuals: a ScrumMasterand a product owner. The ScrumMaster can be thought of as a coach for the team, helping team members use the Scrum framework to perform at their highest level. The product owner represents the business, customers or users and guides the team toward building the right product.

Product Owners and Agile

I’ve been a Product Owner for a number of projects, and it’s a role I find immensely satisfying. You’re the voice of the customer on the project,  and it’s your job to make sure that the work the team is doing matches the business’s needs. As Product Owner you don’t necessarily need to be a technical expert, but you do need a deep understanding of your business and your customers, and the confidence to make fast  decisions.

The Product Owner manages the product backlog, the list of all the things the product needs to be and do. The product backlog is made up of user stories, and your first task in a new project is to sit down and write all the user stories you can think of right now (one of the beauties of Agile is that you can keep adding, removing and modifying user stories throughout the project) and then prioritise them.

Handing over the user stories: sprint planning

The sprint planning meeting is where you see the user stories being put into action. It’s attended by the Product Owner, the Scrum Master, and all the development team.

In the first part of the meeting the backlog will be put in front of the team (perhaps as a spreadsheet, or using a tool like Rally or Pivotal Tracker, or as a bunch of index cards). The team will then ask you questions about any of the user stories that aren’t immediately obvious, and you’ll talk about acceptance criteria. Through this conversation the team will decide which user stories will be tackled in the coming sprint, and what the sprint objective is. You might write this up as a sprint goal: “At the end of this sprint we’ll release the sign-up/log-in functionality to the live site”.

The user stories taken on for a sprint become the sprint backlog. This is all the team will focus on during the sprint – only the Product Owner will be looking at the rest of the product backlog.

The Product Owner isn’t usually present in the second part of the meeting, but I’ve sat in on these sessions (and kept my mouth shut – no doubt a surprise to anyone who knows me well). In this part of the meeting the team puts estimates on each of the user stories. Estimates can be expressed in different ways (story points, complexity points, team hours) but the general idea is that estimates show how much work a user story involves, and are used throughout the project to manage workloads, and predict and track how much work can be done in a given amount of time.

When the estimates are locked in, the team starts work.

User stories throughout a sprint

During a sprint each story will go through a number of stages:

  • not started
  • started
  • in testing
  • finished
  • delivered
  • accepted.

These stages are tracked through online tools like Rally or Pivotal Tracker or with a visible workspace.

Scrum Board by Drew Stephens on Flickr, released under a Creative Commons BY-SA license

During the sprint, the team will hold regular stand-up meetings (maybe every day, maybe on Mondays and Thursdays – whatever works for the pace of the project). As the name suggests, the meetings are held standing up – a physical signal to keep things snappy. At the stand-up the team members will update which stage each user story is at, and talk briefly on three points:

  • What I did yesterday (or over the time since last stand-up)
  • What I’m doing today
  • What’s blocking me (anything that’s stopping them from progressing a user story – e.g. “I haven’t got the wireframes, so I’m blocked on starting the design”).

It’s good to have the Product Owner at the stand-ups, so they can answer any questions on the spot. You’re also likely to be called on throughout the sprint, to review wireframes, to give design briefs, to test out functionality, to answer questions about business needs. As work is completed, each user story will be assigned back to you to ‘accept’ or close: work on a story is complete when the user can achieve the stated goal, and all the acceptance criteria are met.

The aim is to get all the stories in the sprint backlog done before the sprint ends. Stories that run over several sprints are probably badly written (see the INVEST model at the end of this post).

At the sprint retrospective

At the end of the sprint, the team meets again to demonstrate the completed user stories to the Product Owner. Nothing should come as a surprise (you’ve been involved in the work throughout the sprint) but that doesn’t mean you won’t get a sense of delight at seeing finished functionality that’s ready to be released.

The Scrum Master will then lead the team (including the Product Owner) through a retrospective, an analysis of what went well in the sprint, what didn’t go well, what could be changed to make things go better, and any ideas that might improve performance or productivity.

Before the sprint retrospective you’ll have reviewed the product backlog (probably in a meeting with the Scrum Master) and done any rewriting or reprioritising of user stories. After the retrospective the sprint planning starts over again.

And at last, we come to INVEST

INVEST is a mnemonic that describes the qualities of a good user story:

Independent
Negotiable
Valuable to user or business
Estimable
Small
Testable

‘Good’ here means  ‘good for making this whole process work smoothly’, which is why we’ve walked through how a sprint plays out before coming to this definition.

Independent The story stands alone. Stories that are highly dependent on each other are hard to prioritise (“all the stories are equally important”) and hard to estimate (“I can’t put a time on that until we’ve finished that other story”). Problems with dependencies  can be solved by dividing stories differently, or combining several small stories into a single larger one.

Negotiable Remember card – conversation – confirmation? A story should be the starting point for a conversation and an opening for the team to suggest a solution, not a detailed description of how the Product Owner expects that feature or piece of functionality to be implemented.

Valuable It’s all about the end-user. If you can’t describe the value a customer is going to get out of your story, it’s not a good story.

Estimable No estimate, no entry into the sprint backlog. If there’s not enough information or definition to allow the team to put an estimate on a story, it doesn’t get started.

Small A story shouldn’t take longer than a sprint to finish. Any larger than this and it’s hard to estimate or plan for. It’s also likely to be hard to write acceptance criteria and to test.

Testable If you can’t test it, how do you know when a story’s done and working as it should?

Finis

I have one more post planned in this series (which, you’ll be glad to know, will be mercifully shorter than this one). It will look at how you can use user stories to involve people who aren’t working on a project but are interested in its progress and outcome (ie. stakeholders).

In the meantime, if you have any questions about working with Agile, just get in touch – we’re always happy to have a chat.

User stories: a beginner’s guide to acceptance criteria

Last week I described the bones of the user story. Briefly, a user story is a description of an objective a person should be able to achieve when using your website/application/software, written in the following format

As an [actor] I want [action] so that [achievement]

For example:

As a Flickr member I want to be able to assign different privacy levels to my photos so I can control who I share which photos with.

This post adds some flesh to the idea of user stories, in the shape of acceptance criteria.

Where are the details?

At first glance, it can seem like user stories don’t provide enough information to get a team moving from an idea to a product.

Nearly 10 years ago, Ron Jeffries wrote about the Three C’s of the user story:

  • Card – stories are traditionally written on notecards, and these cards can be annotated with extra details
  • Conversation – details behind the story come out through conversations with the Product Owner
  • Confirmation – acceptance tests confirm the story is finished and working as intended.

In a project following an Agile process, user stories are discussed in meetings with the Product Owner (the person who represents the customer for the thing you’re developing, and who writes the user stories) and the development team. The user story is presented, and the conversation starts. For example:

As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork

Questions for the Product Owner might include:

  • What information needs to be collected to allow a user to register?
  • Where does this information need to be collected/delivered?
  • Can the user pay online as part of the registration process?
  • Does the user need to be sent an acknowledgment?

The issues and ideas raised in this Q and A session are captured in the story’s acceptance criteria.

Acceptance Criteria

Acceptance criteria define the boundaries of a user story, and are used to confirm when a story is completed and working as intended.

For the above example, the acceptance criteria could include:

  1. A user cannot submit a form without completing all the mandatory fields
  2. Information from the form is stored in the registrations database
  3. Protection against spam is working
  4. Payment can be made via credit card
  5. An acknowledgment email is sent to the user after submitting the form.

As you can see, the acceptance criteria are written in simple language, just like the user story. When the development team has finished working on the user story they demonstrate the functionality to the Product Owner, showing how each criterion is satisfied.

Including acceptance criteria as part of your user stories has several benefits:

  • they get the team to think through how a feature or piece of functionality will work from the user’s perspective
  • they remove ambiguity from requirements
  • they form the tests that will confirm that a feature or piece of functionality is working and complete.

Further reading

So that’s a brief introduction to acceptance criteria and how they fit in with user stories. For more examples of how acceptance criteria work, I really recommend this post by Sandy Mamoli (Sandy is a Wellington Agile coach and scrum master, who we work with on Digital New Zealand).  You might also like to check out this presentation on effective user stories by Mike Cohn.

Stay tuned for our blog post, where I’ll talk about how user stories get used in the development process, from the perspective of the Product Owner.

User stories: a beginner’s guide

My two favourite things about Agile development:

  1. Communication
  2. User stories.

One of the things I love about user stories (don’t worry, I’ll get to a definition soon) is that they’re a great technique to help people who aren’t used to commissioning websites or applications communicate their requirements.

I had a chat recently with a group of staff from one of our clients who were looking to add a new chunk of content to their website. They’d had a go at using an existing template, and discovered that the way they needed to present this content was quite different from anything they’d tackled so far. In addition they’d been having conversations with some of their customers, who introduced new ideas for how the content could be used.

I suggested that user stories would be a really good way to define and record what the group wanted, and would form a good basis for scoping the work required to deliver new functionality. This post is effectively a record of our conversation.

What is a user story?

A user story is a short description of something that your customer will do when they come to your website or use your application/software,  focused on the value or result they get from doing this thing.

User stories are:

  • written from the point of view of a person using your website or application
  • written in the language that your customers would use.

How do I write one?

The basic technique is simple. You take this format:

An an [actor] I want [action] so that [achievement]

… and fill it out. For example:

As a Flickr member I want to be able to assign different privacy levels to my photos so I can control who I share which photos with.

The actor makes sure you’re thinking about who will use this feature. If there isn’t an identifiable customer for the feature, you should reconsider whether you need it.

The action describes what will happen, but not *how* it will happen (so in the case above, not ‘I want to pick an option from a list of three possibilities, using a radio button display’). User stories are designed to start a conversation within the team about the best way to make this feature.

The achievement describes the ultimate purpose of the feature. If you can’t think of an achievement, that’s a signal that you should reconsider whether the feature you’re trying to describe is actually important.

And that’s the heart of the matter. For a little more detail, check out this post by Mike Cohn on the ‘user story template’. In a later post I’ll cover the INVEST model, the acceptance criteria that get attached to user stories and how user stories get used in the development process.

When do you use them?

User stories are at the core of the Agile project management methodology. However, I believe they are the most useful way of documenting what your website or application needs to do for users, regardless of how you’re running your project.

User stories should be written at the beginning of your project, before you start making any decisions about technical solutions or design. Once they’re written they should be prioritised, from most important to your customer to least important. One of the beauties of Agile is that you can keep writing and reprioritising your user stories throughout the development period.

User stories are an alternative (or possibly a complement) to requirements documents and use cases. These blog posts give good overviews of the advantages and drawbacks of these different techniques for documenting what a website or application needs to do:

Advantages of user stories for requirements – Mike Cohn

Requirements 101: User stories vs use cases – Andrew Stellman

Why use user stories?

Commonly cited benefits of user stories include:

  • they make you think about what you’re building from the end-user’s perspective
  • they lend themselves to prioritisation
  • they can be added to, modified or deleted throughout the development process
  • they capture discrete actions/functionality
  • they can be used in planning people’s work
  • they reduce upfront planning time: you only get stuck into the details when you start working on that story.

Some drawbacks:

  • they can be tricky to write for backend or process tasks
  • they don’t look like a requirements document, and therefore it can sometimes be hard to convince people (often ‘management’) that you’re “following process”.

From my perspective – as someone who’s recently moved over from the client/Product Owner role – the biggest advantage is that user stories don’t make you think about how something will be implemented; instead they focus on the who and the why. This lets clients/commissioners/Product Owners bring their expertise to bear on defining the who and the why, and lets designers and developers bring their expertise to bear on the how. In this way, user stories create a common ground where everyone involved can meet to have a conversation: as I said at the start of this post, Communication and User stories.

Coming soon

Keep an eye on the Boost blog for follow-up posts on the INVEST model, acceptance criteria, and bringing stakeholders onboard with Agile.