User Stories

Steven J Zeil:

Last modified: Dec 21, 2019


User stories are used in incremental SDPMs as a way of organizing work during software construction.

A user story is a simple description of desired functionality, often written as a single sentence on an ordinary index card.

Over time, user stories are modified by

In an incremental construction process, small sets of stories are chosen for an upcoming increment as the target for the next round of construction.

1 User stories

Key idea in all agile variations.

A user story is

1.1 Writing User Stories

1.1.1 Examples of User Stories

As a calendar owner, I want to view my schedule for the coming week.

As a visitor, I want to see when a calendar owner has free time in their schedule.

As a calendar owner, I want to receive email notication when someone accepts a proposed appointment.

As a systems administrator, I want to back up all calendars so that the data is safeguarded.

These illustrate some common patterns:

1.1.2 Stories are not Requirements

…despite the focus on functionality and non-functional characteristics.

1.2 Characteristics of good stories

1.2.1 Customer centric

Stories should express a customer’s point of view, using the customer’s language.

One way to achieve this is to ask the customers to write the stories.

1.2.2 Estimatable

At some point in the process, we must add estimates to our stories indicating how much time we think it will take to complete them. Such estimates aid us in future scheduling. We want to select, for each upcoming increment, enough stories to add a substantial amount of functionality, but not so many that we will be unable to complete them in the time allotted for that increment.

The estimates are commonly not written in hours, person-days or other real time units, at least not unless your team is actually experienced enough to do a good job at coming up with such numbers. Instead, a groups of “typical effort” stories is selected as defining unit 1.0 difficulty, and the others are expresssed in numbers relative to that, e.g., “I think this will take half again as long as the typical stories, so I will estimate it at 1.5.”

1.2.3 Validatable

Good stories have completion criteria that can be validated.

Non-functional stories

Stories can describe new functionality or improvements to existing functionality:

May be harder to define precise completion criteria.

1.2.4 Some Examples of “Bad” Stories

Automate integration build

Improve performance

Implement interfaces between subsystems

1.3 Example (Spreadsheet)

1.4 Special Stories

The traditional user story is customer-centric.

But sometimes there are units of work required that don’t fit the traditional definition.

1.4.1 Documentation stories

1.4.2 Bug Stories

1.4.3 Spike Stories

2 Organizing Constructions via Stories

Remember that each increment is supposed to yield a runnable program that implements some addition functionality not present in earlier increments.

Stories also add functionality, but an individual story might not yield something visible while running the program.

2.1 Planning an Increment

In planning our next increment or release, we select a set of stories to be implemented during our next development interval.

2.1.1 Posting Stories

There are a variety of ways to visually organize stories to enhance planning and to give visual evidence of the progress being made.

2.1.2 Backlogs

A term used in conjunction with story-based planning is “backlog”.

3 Stories become Tasks

When we pick up a story for development there may be many steps required to actually complete it.

It’s possible that a developer will do some tasks on one story, then move to tasks of a second story, then return to the first, etc.

3.1 Tasking Example 1

In the spreadsheet stories, I suggested that the stories for the first increment might be

Of these, I would likely pick

to start.

Then, I would break it into tasks, some of which would be necessitated by this being the first story developed in a project:

  1. Set up project repository

  2. Set up directories and initial build file.

  3. Design initial spreadsheet API.

  4. Write unit test for spreadsheet creation via that API.

  5. Implement the spreadsheet creation function.

  6. Commit implementation to the repository.

Some comments about these tasks:

3.2 Task Boards

3.3 The Definition of Done

"I know you say that you are done. But are you done done? – apocryphal question from one team member to another.

The definition of done is a set of criteria that must be met before a development team agrees that a story has been completed and that the people assigned to it are ready to move on to tackle something else.

Typical Criteria in a Definition of Done

3.3.1 Tasks can Follow the Definition of Done

A common recommendation for division of a story into tasks is to turn each criterion chosen for the teams’ DoD into a task.

3.4 Tasking Example 2 (Spreadsheet)


I consult my task board and decide that I will next work on the story to implement a sqrt operator.

My project “definition of done” says that I must have

  • coded the story (includes writing nad passing unit tests)
  • created a system test
  • integrated the new code

so I would expect to divide this into at least three tasks.

first prev1 of 4next last

4 Thinking Incrementally

To me, one of the challenges in designing good stories and in scheduling them is to envision possible increments.

4.1 Vertical Thinking

Partly, I think this is awkward because there’s a mis-match between how we design and think about code and how we schedule increments.



4.1.1 Iterative Means We Can Come Back

4.1.2 Faking It

If we need to implement part of a complicated ADT during an increment…