A User Story Is a Promise to Talk

Part seven of the product owner toolbox. The story map for the leave tool is full of cards. Now we look at a single card.

A user story describes a piece of functionality from the point of view of a particular user. It’s usually written in plain language using a fixed template, and it’s deliberately short:

As a (role or persona) I want (goal or function) so that (the value)

The template is the least important part. It helps keep the user in mind, but what matters is whether the team can answer four questions: Why are we building this? For whom? Which problem does it solve? And how will we build it technically?

A user story isn’t a fixed, written specification. It’s a promise to have a conversation. Before it gets built, it has to be refined and made concrete in a dialogue with everyone involved.

Card, conversation, confirmation

Ron Jeffries described the three parts of a story as the 3 Cs. The idea behind them is that no requirement can be written down free of misunderstandings.

• Card: The idea, written briefly on a card. Just enough to identify it and give it a first priority. The card is a placeholder on the board.
• Conversation: The story is discussed in person with the people who will build and test it, and ideally with the customer, until everyone understands it the same way. The card gets sharper along the way.
• Confirmation: Once everyone agrees, acceptance criteria are added. They define when the story is accepted, and they fix its scope. The story can also be assessed at this point, for example by value, effort and risk.

Acceptance criteria give developers and testers a concrete picture of what’s expected. They also let the product owner and the stakeholders check whether what was built is what they wanted.

The three amigos

The three amigos (the name comes from George Dinwiddie) take the conversation out of the product owner’s head and put three perspectives in one room:

• Business: Which problem or need are we solving?
• Development: Which solution are we building?
• Testing: Which quality risks are we reducing?

If needed, add more perspectives, such as UX. The three discuss the story until they understand it the same way. Then it’s ready for development.

This is how I run it:

1. The product owner writes the story from the users’ needs and presents it to the team.
2. The team decides who the amigos are for this story. They need to have the skills to build it, all three perspectives need to be covered, and only people who will actually work on it should attend.
3. The product owner organises and moderates the meeting. It’s time-boxed to 30 to 60 minutes, and everyone prepares beforehand.
4. The story leaves the meeting with acceptance criteria.
5. Because everyone shares the same understanding, they can now work in parallel: the product owner updates the product documentation, the tester automates the test cases and the developer writes the code.
6. As soon as the code is done, the tester verifies it and gives feedback. Bugs are fixed in the same sprint, then the product owner accepts the story and it’s shown to the stakeholders in the sprint review.

The result is fewer questions in the middle of the sprint, faster development, testing inside the sprint instead of after it, and less waste.

Behaviour-driven development, which I introduced at Quickline, is essentially this conversation with a fixed output format: the acceptance criteria are written as given, when, then, and they become the automated tests.

A story for the leave tool

As an employee I want to see how many holiday days I have left before I request a week off so that I don’t request days I don’t have.

Acceptance criteria:

• The remaining balance is shown on the request page, above the date picker.
• The balance counts approved and pending requests.
• If the dates I select exceed the balance, I see how many days are missing, and I can’t submit.

The same thing as a scenario:

Given I have 5 days left and 2 days pending
When I select 4 working days
Then I see "1 day more than you have left"
And the submit button is disabled

The second criterion came from the tester in the three amigos meeting. Nobody else had thought about pending requests. That’s the meeting doing its job.

INVEST

Bill Wake’s acronym is a quality check that works for every backlog item, not just stories.

• Independent: It can be built without other items at the same level, so it can be prioritised freely. Complete independence is rare in practice, but check whether splitting differently would remove the dependency.
• Negotiable: It’s not a contract. It leaves room to discuss the solution and the technical approach. Keep the conversation about the user’s need, not about a particular solution.
• Valuable: It delivers value to the user and moves towards the vision. Value is broken down along with the items, so cut stories in a way that each one still delivers something to the user.
• Estimable: The team understands it well enough to estimate effort and complexity. Regular refinement makes this much easier.
• Small: It fits into one sprint. The team decides that, usually with planning poker.
• Testable: You can derive test cases from it, usually through acceptance criteria. That applies to non-functional requirements too.

Who writes stories

Anyone: the team, the stakeholders, the product owner. The product owner stays accountable. Criteria that apply to every story don’t belong on each card. They go into the Definition of Done, which is the topic of the last post in this series.

Next

Most stories are too big when they’re first written. Next time: how to cut them so that each piece still delivers something.