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


 Stories are short descriptions of a small piece of desired functionality, written in the user’s language. They implement small, vertical slices of system functionality, and are sized so they can be completed by the Agile Team in a single iteration.

Stories are the primary artifact used to define system behavior in Agile. They’re not requirements. Rather, they’re short, simple descriptions of functionality the user would like to have, usually told from their perspective and written in their language. Each one is intended to enable the implementation of a small, vertical slice of system behavior that supports incremental development.

Stories provide just enough information for the intent to be understood by both business and technical people. Details are deferred until the story is ready to be implemented. Through acceptance criteria, stories get more specific as they are implemented, helping to ensure system quality.

User stories deliver functionality directly to the end user. Enabler stories bring visibility to the work items needed to support exploration, architecture, and infrastructure.


The Scaled Agile Framework® (SAFe®) describes a four-tier hierarchy of artifacts that outline functional system behavior: Epic > Capability > Feature > Story. Along with Nonfunctional Requirements (NFRs), these Agile requirement artifacts define system and Solution Intent, model system behavior, and build up the Architectural Runway.

Epics, capabilities, features, and Enablers are used to describe the larger intended behavior. But the detailed implementation work is described through stories, which make up the Team Backlog. Most stories emerge from business and enabler features in the Program Backlog, but others come from the team’s local context.

Each story is a small, independent behavior that can be implemented incrementally and provides some value to the user or the Solution; it’s a vertical slice of functionality to ensure that every Iteration delivers new value. To accomplish this, stories are split as necessary so they can be completed in a single iteration (see below).

Often, stories are first written on an index card or sticky note. The physical nature of the card creates a tangible relationship between the team, the story, and the user: It helps engage the entire team in story writing. Sticky notes offer other benefits as well: They help visualize work and can be readily placed on a wall or table, rearranged in sequence, passed around, and even handed off when necessary. They allow teams to better understand scope and progress:

  • “Wow, look at all these stories I’m about to sign up for.” (scope)
  • “Look at all the stories we accomplished in this iteration.” (progress)

While anyone can write stories, approving them into the team backlog and accepting them into the system baseline is the responsibility of the Product Owner (PO). Of course, stickies don’t scale well across the Enterprise, so stories often move quickly into Agile project management tooling.

There are two types of stories in SAFe, user stories and enabler stories, as described below.

Sources of Stories

In SAFe, stories are generally driven by splitting business features and enabler features, as Figure 1 illustrates.

Figure 1. Example of a business feature split into stories

User Stories

User stories are the primary means of expressing needed functionality. They largely replace the traditional requirements specification. (In some cases, however, they serve to explain and develop functionality that’s later recorded to support compliance, traceability, or other needs.)

Because they focus on the user as the subject of interest, and not the system, user stories are value centric. To support this, the recommended form of expression is the ‘user voice form,’ as follows:

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

By using this format, the teams are constantly guided to understand who is using the system, what specifically they are doing with it, and why they are doing it. Applying the user voice routinely tends to increase the team’s domain competence; they come to better understand the real business needs of their user. Figure 2 provides an example:

Figure 2. Example User Story in user voice form
Figure 2. Example user story in user voice form

While the user story voice is the common case, not every system interacts with an end user. Sometimes the ‘user’ is a device (example: printer) or other system (example: transaction server). In these cases, the story can take on the form illustrated in Figure 3.

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

Enabler Stories

Teams also need to develop the technical functionality 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. These are enabler stories, and they can support exploration, architecture, or infrastructure, just like all other enablers. In these cases, the story can be expressed in technical rather than user-centric language, as Figure 4 illustrates.

Figure 4. Example enabler story
Figure 4. Example enabler story

Enabler stories may include any of the following:

  • Refactoring and Spikes (as traditionally defined in XP)
  • Building or improving development/deployment infrastructure
  • Running jobs that require human interaction (example: Index 1 million web pages )
  • Creating required product or component configurations for different purposes
  • Performing special types of system qualities verification (vulnerability testing, etc.)
  • And, of course, enabler stories are demonstrated just like user stories, typically by showing the artifacts produced or via UI, stub, or mock.

Writing Good Stories

The 3Cs: Card, Conversation, Confirmation

Ron Jeffries, one of the inventors of XP, is credited with describing the ‘3Cs’ of a story:

Card – represents capturing the statement of intent of the user story on an index card, sticky note, or tool. The use of index cards provides a physical relationship between the team and the story. The card size physically limits story length and premature suggestions for specificity of system behavior. Cards also help the team ‘feel’ upcoming scope, as there is something materially different about holding 10 cards in one’s hand versus looking at 10 lines on a spreadsheet.

Conversation – represents a “promise for a conversation” between the team, Customer/user, Product Owner, and other stakeholders. This is the discussion necessary to determine more detailed behavior required to implement the intent. The conversation may spawn additional specificity in the form of attachments to the user story, i.e., mock-up, prototype, spreadsheet, algorithm, timing diagram, etc. The conversation spans all steps in the story life cycle:

  • Backlog refinement
  • Planning
  • Implementation
  • Demonstration

Conversations provide a shared context that cannot be achieved through formal documentation. They replace ambiguity with concrete examples of functionality. Conversations also help uncover gaps in scenarios and NFRs. Some teams also use the confirmation section of the story card to write down what they will demo for the story.

Confirmation – The acceptance criteria provides the precision necessary to ensure that the story is implemented correctly and covers the relevant functional and nonfunctional requirements. Figure 5 provides an example.

Figure 5. Story acceptance criteria

Agile Teams automate acceptance tests wherever possible, often in business-readable, domain-specific language. This creates an “automatically executable specification and test” of the code. Automation also provides the ability to quickly regression-test the system, enhancing Continuous Integration, refactoring, and maintenance.

Invest in Good Stories

To remind themselves of the elements of a good story, people often use the mnemonic INVEST, developed by Bill Wake:

  • I – Independent (of all other stories)
  • N – Negotiable (a flexible statement of intent, not a contract)
  • V – Valuable (providing a valuable vertical slice to the Customer)
  • E – Estimable (small and negotiable)
  • S – Small (fits within an iteration)
  • T – Testable (understood enough to know how to test it)
  • Refer to [1] and [2] for more information

Estimating Stories

Agile Teams use story points and ‘estimating poker’ [2 and 3] to value their work. A story point is a singular number that represents a combination of qualities:

  • Volume – How much is there?
  • Complexity – How hard is it?
  • Knowledge – What’s known?
  • Uncertainty – What’s unknown?

Story points are relative; they are not connected to any specific unit of measure. The size (effort) of each story is estimated relative to the smallest story, which is arbitrarily assigned a size of 1. SAFe applies the modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) to reflect the inherent uncertainty in estimating, especially large numbers (e.g. 20, 40, 100, etc.) [2]

Estimating Poker

Agile Teams often use ‘estimating poker,’ which combines expert opinion, analogy, and disaggregation for quick but reliable estimates. (Note that there are a number of other methods used as well.) The rules of estimating poker are:

  • Participants include all team members.
  • Each estimator is given a deck of cards with 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, and?
  • The PO participates but does not estimate.
  • The Scrum Master participates but does not estimate; an exception is if he or she is doing actual development work.
  • For each backlog item to be estimated, the PO reads the description of the story.
  • Questions are asked and answered.
  • Each estimator privately selects an estimating card representing his or her estimate.
  • All cards are simultaneously turned over so that all participants can see each estimate.
  • High and low estimators explain their estimates.
  • After a discussion, each estimator re-estimates by selecting a card.
  • The estimates will likely converge. If not, the process should be repeated.

Some amount of preliminary design discussion is appropriate. However, spending too much time on design discussions is often wasted effort. The real value of estimating poker is to come to a common agreement on the scope of a story. It’s also fun!


The team’s velocity for an iteration is equal to the sum of the points for all the completed stories that met their Definition of Done (DoD). Knowing the velocity assists with planning and is a key factor in limiting Work in Process (WIP), as teams don’t take on more stories than their prior velocity would allow. Velocity is also used to estimate how long it takes to deliver larger epics, features, capabilities, and enablers, also estimated in story points.

Common Starting Baseline for Estimation

In standard Scrum, each team’s story point estimating—and the resulting velocity—is a local and independent concern. Even if a small team might estimate in such a way that they have a velocity of 50, while a larger team has a velocity of 12, it’s of no concern to anyone outside the team.

In SAFe, however, story point velocity must have a common starting baseline, so that estimates for features or epics that require the support of many teams are based on rational economics. To achieve this, SAFe teams start down a path on which a story point for one team is roughly the same as a story point for another. This means that, with adjustments for economics of location (U.S., Europe, India, China, etc.), work can be estimated and prioritized based on converting story points to cost. After all, there’s no way to determine the potential return on an investment if there is no common ‘currency.’

The method for getting to an agreed starting baseline for stories and velocity is as follows:

  • Give every developer-tester on the team eight points (adjust for part-timers).
  • Subtract one point for every team member vacation day and holiday.
  • Find a small story that would take about a half-day to code and a half-day to test and validate. Call it a one (1).
  • Estimate every other story relative to that one (1).

Example: Assuming a six (6)-person team composed of three (3) developers, two (2) testers, and one PO, with no vacations or holidays, the estimated initial velocity = 5 x 8 points = 40 points/iteration. (Note: Adjusting a bit lower may be necessary if one of the developers and testers is also the Scrum Master.)

In this way, story points are somewhat comparable to an ideal developer day, and all teams estimate work size in a common fashion. This allows management to fairly quickly estimate the cost for a story point for teams in a specific region. Then they have a meaningful way to figure out the cost estimate for an upcoming feature or epic.

Note: There is no need to recalibrate team estimation or velocity after that point. It is just a common starting baseline.

While teams will tend to increase their velocity over time—and that’s a good thing— in reality the number tends to remain fairly stable. A team’s velocity is far more affected by changing team size and technical context than by productivity variations. If necessary, financial planners can adjust the cost per story point a bit. Experience shows that this is a minor concern, versus the wildly differing velocities that teams of comparable size may have if they don’t set a common starting baseline. That simply doesn’t work at enterprise scale, and economic decisions can’t be based made that way.

Splitting Stories

Smaller stories allow faster, more reliable implementation, since small things go through a system faster, reducing variability and managing risk. Splitting bigger stories into smaller ones is, thus, a mandatory survival skill for every Agile Team. It’s both the art and the science of incremental development. Ten ways to split stories are highlighted in [1]. A summary of these techniques is shown below.

  1. Work flow steps
  2. Business rule variations
  3. Major effort
  4. Simple/complex
  5. Variations in data
  6. Data entry methods
  7. Deferred system qualities
  8. Operations (example: Create Read Update Delete, or CRUD)
  9. Use-case scenarios
  10. Break-out spike

Figure 6 illustrates an example of #9, splitting by use-case scenarios.

Figure 6. An example of splitting a large story into smaller stories

Stories in the SAFe Requirements Model

As described in the SAFe Requirements Model, the framework applies an extensive set of artifacts and relationships to manage the definition and testing of complex systems in a Lean and Agile fashion. Figure 7 illustrates the role of stories in this larger picture.

Figure 7. Stories in the SAFe Requirements Model

Figure 7 illustrates how stories are often (but not always) spawned by new features, and how each has an associated story acceptance test. Further, in XP and SAFe ScrumXP, each story should have a unit test associated with it. Unit tests primarily serve to ensure that the implementation of the story is correct. In addition, this is a critical starting point for test automation, as unit tests are readily able to be automated, as described in Test-First.

Note:  Figure 7. uses UML notation to represent the relationships between the objects: zero to many (0,1), one to many (1..*), one to one (1) and so on.

Learn More

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

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

Last update: 28 September, 2018