User stories in action – the Agile development process

Agile , , , , 3 Comments

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

Agile , , , , 3 Comments

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

An 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

Agile , , , , , 4 Comments

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.