Over the last few weeks, I’ve written alot about writing good User Stories – you can see them all here: User Stories.

User Stories are a simple way of capturing user requirements throughout a project – an alternative to writing lengthy requirements specifications all up-front.

As a guide for people writing User Stories, they can follow this basic construct:

As a [user role], I want to [goal], so I can [reason].

This helps to ensure that the requirement is captured at a high level, is feature oriented and covers who, what and why.

As well as capturing User Stories in the above format on the Product Backlog, User Stories should be written on a card.

The card comprises 3 parts:

  • Card (i.e. the bit above, “as a user, I want…”)
  • Conversation (notes and/or small wireframe to remind people about the feature)
  • Confirmation (the tests that will show the feature is complete)

Here’s an example User Story for you to take a look at.

Ultimately, User Stories should be small. But when they’re first entered on the Product Backlog, when they’re quite a way from being developed, they can start out large and fuzzy. While they are in this state, they are known as Epics.

Software requirements are a communication problem. There is no perfect solution. User Stories seek to find a balance between written and verbal requirements, relying on collaboration between team members to clarify details near the time of development.

Here’s a PowerPoint presentation about User Stories to help share the concept with others.

The INVEST acronym can help you to remember and assess what makes a good User Story. User Stories should be:

* Independent. Okay, for some systems, it’s near impossible to make each feature completely independent. In other solutions, e.g. web sites, it’s easier. But it’s an important aspiration. User Stories should be as independent as possible.

* Negotiable. User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development.

* Valuable. User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.

* Estimable. User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.

* Small. User Stories should be small. Not too small. But not too big!

* Testable. User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.

I hope this series of posts has been useful…

Kelly.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

An Interview with Kevin Gaskell: How to go from ordinary to extraordinary

A conversation with Kevin Gaskell: business man, leader, investor, entrepreneur, author, speaker, and record-breaking adventurer. “All ordinary people have the potential to be extraordinary” Occasionally you meet someone truly inspirational. Extraordinary, even. Kevin Gaskell is certainly one of those people. He’s led some of the world’s most iconic brands, including Porsche, BMW and Lamborghini. He’s started successful businesses. Invested in

Read More »

In The Zone with Marcin Zasepa

Welcome to the second in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Marcin Zasepa, CTO at Homegate AG in Switzerland. Every episode will be approximately 30 minutes

Read More »

In The Zone with Sasha Bilton

Welcome to the first in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Sasha Bilton. Every episode will be approximately 30 minutes long, and we aim

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?

London

101 Ways Limited
145 City Rd
London
EC1V 1AZ
United Kingdom

Amsterdam

101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam
Netherlands

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at contact-us@101ways.com.