The Agile Software Vendor (Part 2 – Writing Good User Stories)

April 20, 2012 gschottland

In our first post on agile development from January (, we discussed the basics of the Agile software development process and why it is good for software vendors and their customers. This article looks at what makes a good User Story – the core of defining requirements.

What exactly is a User Story? User Stories are simply requirements. But, as with everything in Agile, we both simplify and specify the process. Instead of massive requirements documents that are understood only by a handful of business analysts, Agile User Stories are short, simple and easy to understand descriptions of functionality.

Short – typically limited to one page.

Simple –  Describes one or more “atomic” (small) pieces of functionality.

Easy to Understand – Uses short, succinct sentences and pictures to clarify things.

A good way to think of (and start writing) a user story is using the below phrase as a template:

As a <role/persona>, I want to <action to perform>, so that I can <obtain a benefit>.

This simple sentence is the basis of any good User Story, and while a statement of this type often seems overly simple – that’s the point! We want to identify simple, clear, small pieces of functionality.

But User Stories hold one more ever-so-important piece: the test. How do you prove the functionality works? This is typically described in clear, simple, user-level focused tests. In fact many would argue that the test is the story – and I’d completely agree.

So, let’s dig into an example. I have an idea for an earth-shaking iPhone app: “Time Shaker.” What is it? What does it do? Well, let’s jump in with a simple user story for my app:

As an iPhone user, I can shake my iPhone so I can see the current time without having to touch the screen.

Ok, so maybe not the most earth-shattering, but notice how this one, succinct sentence covers a lot of ground. I have specified:

My platform: an iPhone

What users have to do: Shaking

What users don’t have to do: tapping the screen

What happens: the time is displayed.

Now the ever-important test (or proof) that once we implement it, it works:

  1. 1. Shake iPhone (don’t touch screen at all)
  2. 2. iPhone screen clears.
  3. 3. Time appears in the center / top of the iPhone top status bar

So, we can put this all together, with a simple picture, to capture the essence of our new app.

Simple and clean, isn’t it. So, you may think, hey, that user story is trivial, what about the real world? In truth, this is the real world. If you spend time and layout a piece of new functionality, you can break down even the largest of functions into a set of smaller user stories. Agile helps by creating the concept of Epic (larger User Stories that may break down into smaller User Stories) and Themes (a set of related User Stories that implement a larger whole. So, the idea (and the challenge) is to write complete, larger descriptions of functionality as a Theme for example, then construct many smaller User Stories that actually implement that theme, yet are small enough to be easily implemented and tested.

It sounds easy, and it is!

By Greg Schottland, Vice President of Operations at Xyleme, Inc.

Previous Article
Instructional Design Orthodoxy
Instructional Design Orthodoxy

I will be dating myself here, but so much of the orthodoxy in the...

Next Article
When the Learner is the Teacher, Do We Need Instructional Designers?
When the Learner is the Teacher, Do We Need Instructional Designers?

It’s a new world out there for the Instructional Designer. It’s an...