Stories act as a “pidgin language” where both sides (users and developers) can agree enough to work together effectively.

— Bill Wake, Co-inventor of Extreme Programming

Every story tells a picture, don’t it……

– not a Rod Stewart song

Stories Abstract

In SAFe, the Teams’ backlog contains all the work a team needs to do to define/build/test and deliver value. Most of this work represents new system behaviors that the team needs to implement. Traditionally, expressing intended system behavior has been captured in Software Requirements Specifications (“the system shall…”). In agile however, this traditional document is replaced (except where mandated by regulation or customer/business requirements) by a series of stories (primarily user stories), which express the intent of the system. Stories are small, independent behaviors that can be implemented incrementally, each of which provides some value to the user. To assure that every iteration delivers new value, stories are split as necessary so they can be completed in a single iteration.

Stories are not requirements, in that they are generally negotiable and thereby represent a statement of intent rather than a contractual (internally or externally) specific behavior. However, through acceptance criteria, stories get more specific as they are implemented, providing the necessary specificity for assuring system compliance and regression testing.

In this article, we’ll describe the user story, wherein each story answers the question “who does what with this system, and why do they do it?” In addition, we’ll describe the technical story, which is used to describe other types of necessary system behavior.

Details

Large-scale system development is inherently complex, and there a number of types of stories that teams can use to represent intended system behavior and other work. This is indicated in the SAFe enterprise backlog model in the form of user stories and “other work items”, as illustrated in Figure 1.

Figure 1. Story and related objects in the backlog metamodel

As can be seen from Figure 1, ALL stories have associated acceptance tests and are implemented by tasks. Most all stories, at least those that cause new code to be created, also require one or more associated unit tests. In this article, we’ll discuss the two types of stories that define new functionality User Stories and Technical Stories.

Stories are small, simple chunks of value. Initially, they are typically written on an index card (either a physical card or a card metaphor in software tool). Each story is understandable by the user, the Product Owner (the agile team-based user proxy who typically defines and prioritizes most stories) and the Developers and Testers responsible for implementing it. The value-centric format and the tangibility of a physical story card help engage the entire team, as well as users where applicable, in story writing. However, approving user stories into the backlog and accepting them into the main line development is the responsibility of the product owner.

User Story

The primary carrier of system behavior and user value is the User Story. User stories are user and value centric, as they put the user, not the system, as the target of interest. The recommended form of expression is the user voice form, and it appears as follows:

As a 〈user role〉 I can 〈activity〉 so that 〈business value〉,

By using this form, the teams are constantly forced to understand who is using the system, what they are specifically doing with it, and why they are doing it. Applying it routinely continuously increases the team’s domain competence as they come to better understand the real business needs of their user. Here is an example:

Figure 2: Example of a user story.

User stories also follow the XP alliteration of the “3Cs”: Card (short statement of intent), Conversation (discussion with the user/product owner and team), and Confirmation (acceptance criteria which define the conditions of satisfaction for the completed story).

Card represents the physical capture of the statement of intent of the user story. The card metaphor provides a tangible and kinesthetic relationship between the team and “this thing a user wants to do”. By its nature, the card physically limits the length of the story, and thereby, too-early specificity of system behavior. It also helps keep k3eeps the story lightweight and malleable. Cards also help the team “feel” upcoming scope. (There is something materially different holding 10 cards in ones hand that is than looking 3at 10 lines on a spreadsheet.)

Conversation represents a “promise for a conversation” between the team, customer/user, the product owner, and other stakeholders. This is the discussion necessary to determine the more detailed behavior required to implement the intent. The conversation may spawn additional specificity in the form of attachments to the user story (mockup, spreadsheet, algorithm, timing diagram, etc).

Confirmation. While user stories are intentionally written as short and coarse statements, the stories acceptance criteria provides the precision necess3ary to assure that the story is implemented correctly and covers the relevant functional and non-functional requirements. Agile teams automate acceptance tests wherever possible, oftentimes in a business-readable, domain-specific language, thereby creating the “automatically executable specification and test” of the code. Automation also provides the ability to quickly regression test the system which enhances, continuous integration, refactoring and maintenance. Figure 3 provides an example.

Figure 3: Story acceptance test written in Gherkin language for Cucumber acceptance testing framework

Some teams also use this third section of the story card to write down what they will demo for the story.

Investing in Good User Stories

Teams often use Bill Wake’s “INVEST” acronym (Independent, Negotiable, Valuable, Estimable, Small, Testable; see References [1] and [2]) to reason about stories.

Device or a System User Story

While the user story is the primary, and most desirable form of story, not every system under development interacts with an end user. Sometimes, the “user” is a device (example: printer) or other system (example: transaction server). In this case, the story takes on the form illustrated in Figure 4.

Figure 4. Example of a user story with a system as a user

Technical Stories

Sometimes, the development teams must develop component functionality that is needed to implement a number of different user stories, or support other components of the system. In this case, the story may not directly touch any end user at all, and we can express these stories in technical, rather than user-centric language, as Figure 4 illustrates.

Figure 5. Example of a technical story

Even then, however, we recommended keeping the “…so that…” portion of the form so that the motivation for the story is understood. And of course, technical stories are demonstrated just like user stories, typically via UI, stub or mock.

Technical stories are most heavily used in developing and modifying components of large-scale systems. (See Features & Components). Technical stories can be applied whenever a) the scope of work is constrained to a single subsystem or component; b) there is no single, obvious external user, device or system. Otherwise, the user story form should be applied.

Splitting Stories

Smaller stories allow for faster, more reliable implementation (small things go through a system faster, reduce complexity and manage risk). Splitting bigger stories into smaller ones is thus a mandatory survival skill for every agile team, and is both the art and science of incremental development. In Ref [1], we highlighted ten ways to split user stories. A summary of these techniques is included below. We split stories by

Workflow steps
Business rule variations
Major effort
Simple/complex
Variations in data
Data entry methods
Defer system qualities
Operations (Example: Create Read Update Delete (CRUD))
Use-case scenarios
Break out a spike

Figure 3 illustrates an example of “split by workflow steps)”:

Figure 6: The Figure 1 user story split into two smaller user stories

On Story Points and Velocity

Because of the atomic nature of a story (it delivers value by itself and is Defined/Built/Tested as a unit), an estimate can be derived in terms of “story points” that predict the level of effort necessary to implement a fully tested story. The average aggregation of story points for all stories completed during an iteration becomes that team’s “velocity”, which serves as an estimating mechanism and Work in Process limit for future iterations. (See Iteration Planning). In addition, in SAFe, an “approximate normalization” of story points across teams and programs allows for more accurate and flexible program estimating and planning.

Other Team Backlog Items

In addition to these system behavior stories, other Team Backlog items include Spikes and Refactors, each of which is described in its own SAFe article. In addition, there are other backlog items that provide value and require effort, but are not directly related to new code. These often stem from:

Building or improving development/deployment infrastructure
Running jobs that require human control (example: Index 1 million web pages so that we can build the initial data base and establish performance measures))
Creating required product or component configurations for different purposes
Performing special types of system qualities verification (vulnerability testing etc.)

Summary

Stories are the currency of agility – they bridge the gap between business and technology and foster fast incremental development. There are a variety of story forms teams can use, based on their context in the overall system development. Each requires an understanding of intent and rationale, and each deserves acceptance testing and demonstration. In this way, develop proceeds incrementally, one story at a time, with every story adding value to the user and the business.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011, chap. 6.

[2] Cohn, Mike. Beck, Kent. User Stories Applied: For Agile Software Development. Addison-Wesley, 2004.

Last update 15 January, 2013