Agile Software Development

The concept of writing user stories, as a way of documenting requirements, was introduced and popularized with Extreme Programming, and then picked up by Scrum and several other agile methods. Nowadays, for many agile developers, a project without user stories would be like a world without pizza. Impossible to imagine.

User Stories Applied
The book User Stories Applied, published in 2004 by Mike Cohn, is a landmark publication that has brought together everything the agile movement has learned about this important subject. Mike's book deals with all the activities that people have to perform when writing user stories, like techniques for requirements gathering, defining roles, working with user proxies, and preparing for acceptance testing. Mike also clearly explains how user stories can play a pivotal role in the wider agile project management processes of estimating, planning and monitoring.

User Stories are a not mandatory, but very recommended part of Scrum and eXtreme Programming methods. Most of people acquainted with agile software development feel comfortable with the requirements written in the form of "As a [user role] I want to [goal], so that [reason]". Less people are acquainted with epics and themes usage.

Terms

Epics are just huge stories for capturing relatively low priority requirements that are often too complex to estimate right away and that are going to be detailed later. An epic for a car could be "As an environment conscious driver I want to be able to use both gas and hydrogene". A theme on the other hand is a set of stories grouped around some functional area, user group or anything else that makes sense for the product owner. Themes are often confused with epics, because quite often the epic is split down into exactly one theme. A theme for a car could be a set of stories grouped around the building the hydrogen engine.

Stories or User Stories is the XP practice of thinking about software in terms of units of customer-visible functionality. A canonical form of a user story looks like "As a <user-type> I want to a <goal> so that <reason>". For example, "As a Frequent Flier, I want to rebook a trip so that I save time when booking trips I take frequently" (from Mike Cohn's User Stories applied).

This is part 4 of a series of articles on Distributed Agile Development. In this article I will talk about the problems that are faced when writing user stories in a distributed development scenario, and how the INVEST approach can falter.

I published an article introducing the 3 C's and the INVEST approach when it comes to write user stories. One of the most important lessons of that article is that there is a need to negotiate/communicate with the end user while developing the user story.

Advertisement:

What is a User Story?

A user story describes desired functionality from the customer(user) perspective. A good user story describes the desired functionality, who wants it, and how and why the functionality will be used. The basic components of a User Story are sometimes dubbed as the three C's: