The life of a user story

Creating The Project Vision

We typically kick off projects at TPXimpact with a workshop to establish a joint vision. We bring together stakeholders and the core team to determine who the users are, what their needs are, the features the product can offer to meet those needs and the value the features create (both for the user and the business).

Then the core delivery team discusses how we’ll actually deliver the work. This involves answering questions such as:

• What methodology will we use to manage the project? (Kanban, Scrum, or hybrid)

• What style of user stories will we write?

• Who’ll own the backlog?

• How long will our sprint cycles be?

• When is a story ready for development (Definition of Ready)?

• When is a story finished (Definition of Done)?

These are critical decisions that will affect how smoothly the rest of the project is delivered.

Populating the Backlog

The next step is to translate the ‘Features’ from the product vision session into user stories. These will populate a development backlog which will be used throughout the rest of the project. It’s interesting to consider, in practice, who owns this process. It is the project manager? The product owner? Perhaps it’s the Business Analyst or someone else in the team? At TPXimpact, the answer is everyone. Here’s how we do it.

At this stage the user story only needs to describe the feature in broad brush strokes — we’re not about to start building the feature yet — but it’s best if it does so in terms of who the user is, what they need and the value that the feature adds.

For example:

As a tea drinker, I want to pick up my tea by a handle, so that I don’t burn my hands.

Anybody who reads the story not only knows which feature it describes but also who the feature is for and why it’s being provided.

Producing this initial backlog can be a collaborative effort or led by one of the team. It’s ultimately approved by the Product Owner who’ll confirm if it represents the end product as they see it.

Refining the Backlog

Now it’s time to bring some of the key team members together to start fleshing the stories out.

You don’t need the whole team for this (which is good, because getting everyone together before the project has started is often impossible). We like to refine the backlog with, as a minimum, the ‘Three Amigos’ — the Product Owner (or a BA), a developer and a designer (or UX designer).

The aim of this meeting is to prioritise and estimate the size of the stories in the backlog, but before we can do that we need to sketch out our ideas and proposed solutions. At this stage, you might find that some of the original stories get broken down into several component stories.

For example, our earlier story might turn into an Epic which contains the following stories:

As a tea drinker, I want my tea in a mug so that I can pick it up.

As a tea drinker, I want my mug to have a handle so that I don’t burn my hands.

The refinement session aims to tease out this kind of detail. In particular, we want to give each story a set of acceptance criteria so that we know when the story is Done. We like to write acceptance criteria as scenarios in the ‘Given, When, Then’ format which set out very clear tests (you can even turn these into automated test scripts if you’re so inclined) e.g.

Given I am a ‘tea drinker’

When I visit ‘my beverage’

Then I see ‘a mug with a handle’

By going through this process for each story it will quickly become clear whether each story is of a testable size.

The Sprint Planning Session

Sprint planning is where we work out how we actually do the work and agree on the order we’ll work on it. As an agency, before we get to planning the first sprint we will often have presented our proposed solutions, and perhaps even the backlog itself, to the client, providing further opportunities to spot errors or misunderstandings and to refine the backlog further. In house teams might like to replicate this opportunity by demoing their solutions to the major stakeholders.

The whole team is required for sprint planning. It’s not only where they’ll find out what they’re working on but also an opportunity to talk through the tasks required, challenge any previous assumptions, including estimates, and check that stories and acceptance criteria are really Ready for development. Often new stories will be written and estimated as those deemed too large for a single sprint are broken down into more digestible portions.

By the end of the meeting, the backlog for the first sprint should be settled, full of stories which include acceptance criteria and, where front-end development is required, sketches and wireframes.

The Sprint

In theory, the stories have all the detail they need for developers to turn them into working features. In reality, one or two underdeveloped stories will probably have slipped through the net (probably towards the end of planning when everyone was flagging a bit).

Not to worry. As long as your team is communicating well (you are having daily stand ups, aren’t you?) there should be plenty of opportunity for rooting out those thin stories, rewriting acceptance criteria or redrawing wireframes where necessary and getting them back in the sprint backlog.

And if the story can’t be rehabilitated for this sprint then, provided it describes a feature, not a whole raft of functionality, you should be able to descope it for now without affecting the rest of the sprint too much. One of the best things about working in an Agile way is that we can handle problems like this without derailing the whole project.

The acceptance criteria really come into their own now as they are used to determine beyond doubt which stories meet all their acceptance tests and can be deemed done or ready for release.

The Demo

With the sprint over, we should have a working bit of software that we can demo to the client/stakeholders. During the demo meeting, user stories provide a good framework to report on which work has and hasn't been done.

It’s also an opportunity for stakeholders to feedback on the product and suggest improvements. These suggestions can be written up as new user stories by the Product Owner and taken to the next backlog refinement meeting.

The Retrospective Meeting

Agile values people and interactions over processes and tools, so we should get together to talk about what we’ve done and how we can work better together after every sprint. If we’re not working in sprints, then we should get together for a retrospective at least often enough that we can act on our insights.

In the retrospective meeting, user stories normally take a back seat to the discussion of communication tools and meeting structures. But try to find time to talk about whether the definitions of ‘done’ and ‘ready’ need to be addressed and the adequacy (or not) of acceptance criteria.

It’s a constant process of iteration and refinement but the goal is to find a consistent user story ‘template’ that makes features easy to understand and provides clarity on when a story is ready for the next stage of its life cycle.