Story Flashcards
Story
Stories are short descriptions of a small piece of desired functionality, written in the user’s language.
Agile Teams implement small, vertical slices of system functionality and are sized so they can be completed in a single Iteration. Stories are the primary artifact used to define system behavior in Agile.
They are short, simple descriptions of functionality usually told from the user’s 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 both business and technical people to understand the intent.
Details are deferred until the story is ready to be implemented.
Through acceptance criteria and acceptance tests, stories get more specific, 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, infrastructure, and compliance.
Story Details
SAFe’s Requirements Model describes a four-tier hierarchy of artifacts that outline functional system behavior: Epic, Capability, Feature, and story. Collectively, they describe all the work to create the solution’s 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. Stories are small and must be completed in a single iteration (see the splitting stories section).
Sources of Stories
Stories are typically driven by splitting business and enabler features, as Figure 1 illustrates.
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 as a means to explain and develop system behavior that’s later recorded in specifications that support compliance, suppliers, traceability, or other needs.
Because they focus on the user as the subject of interest, and not the system, user stories are value and customer-centric.
To support this, the recommended form of expression is the ‘user-voice form’, as follows: As a (user role), I want to (activity), so that (business value)/
Enabler Stories
Teams also develop the new architecture and infrastructure needed to implement new user stories. In this case, the story may not directly touch any end user. Teams use ‘enabler stories’ to support exploration, architecture, or infrastructure. Enabler stories can be expressed in technical rather than user-centric language
There are many other types of Enabler stories including:
Refactoring and Spikes (as traditionally defined in XP) Building or improving development/deployment infrastructure
Running jobs that require human interaction (e.g., index 1 million web pages)
Creating the required product or component configurations for different purposes
Verification of system qualities (e.g., performance and vulnerability testing)
Enabler stories are demonstrated just like user stories, typically by showing the knowledge gained, artifacts produced, or the user interface, stub, or mock-up.
The 3Cs: Card, Conversation, Confirmation
Card –
Captures the user story’s statement of intent using an index card, sticky note, or tool. Index cards provide a physical relationship between the team and the story. The card size physically limits story length and premature suggestions for the specificity of system behavior. Cards also help the team ‘feel’ upcoming scope, as there is something materially different about holding ten cards in one’s hand versus looking at ten lines on a spreadsheet.
Conversation –
Represents a “promise for a conversation” about the story between the team, customer (or the customer’s proxy), the PO (who may be representing the customer), and other stakeholders. The discussion is necessary to determine more detailed behavior required to implement the intent. The conversation may spawn additional specificity in the form of acceptance criteria (the confirmation below) or attachments to the user story. The conversation spans all steps in the story life cycle: Backlog refinement Planning Implementation Demo These just-in-time discussions create a shared understanding of the scope that formal documentation cannot provide. Specification by example replaces detailed documentation. Conversations also help uncover gaps in user scenarios and NFRs.
Confirmation –
The acceptance criteria provides the information needed to ensure that the story is implemented correctly and covers the relevant functional and NFRs. Figure 5 provides an example. Some teams often use the confirmation section of the story card to write down what they will demo.
Investing in Good Stories
Bill Wake, coined the acronym INVEST [1], to describe the attributes of a good user story.
I – Independent (among 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)
Splitting Good Stories
Smaller stories allow faster, more reliable implementation, since small items flow through any system faster, with less variability, and reduced risk. Therefore, splitting bigger stories into smaller ones is a mandatory skill for every Agile team. It’s both the art and the science of incremental development. Ten ways to split stories are described in Agile Software Requirements [1]. A summary of these techniques follows:
Estimating Stories
Agile teams use story points and ‘estimating poker’ to value their work [1, 2].
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, without a connection to any specific unit of measure.
The size (effort) of each story is estimated relative to the smallest story, which is assigned a size of ‘one.’ A modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) is applied that reflects the inherent uncertainty in estimating, especially large numbers (e.g., 20, 40, 100) [2].
Estimating Poker
Agile teams often use ‘estimating poker,’ which combines expert opinion, analogy, and disaggregation to create quick but reliable estimates.
Disaggregation refers to splitting a story or features into smaller, easier to estimate pieces. (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 unless they are 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 turned over at the same time to avoid bias and to make all estimates visible.
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 is 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 an agreement on the scope of a story. It’s also fun!
Velocity
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). As the team works together over time, their average velocity (completed story points per iteration) becomes reliable and predictable. Predictable velocity assists with planning and helps limit Work in Process (WIP), as teams don’t take on more stories than their historical velocity would allow. This measure is also used to estimate how long it takes to deliver epics, features, capabilities, and enablers, which are also forecasted using story points.
Capacity
Capacity is the portion of the team’s velocity that is actually available for any given iteration. Vacations, training, and other events can make team members unavailable to contribute to an iteration’s goals for some portion of the iteration.
This decreases the maximum potential velocity for that team for that iteration. For example, a team that averages 40 points delivered per iteration would adjust their maximum velocity down to 36 if a team member is on vacation for one week.
Knowing this in advance, the team only commits to a maximum of 36 story points during iteration planning. This also helps during PI Planning to forecast the actual available capacity for each iteration in the PI so the team doesn’t over-commit when building their PI Objectives.
Stories in the SAFe Requirements Model
As described in the SAFe Requirements Model article, 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.
