Essential Scrum – Sprints, Requirements and User Stories (3)


  • They are timeboxed
  • Have a short and consistent duration
  • Have a goal that shouldn’t be altered once started
  • Must reach the end state specified by the team’s definition of done.


  • Establishes a WIP Limit
  • Forces Prioritization
  • Demonstrates Progress
  • Avoids Unnecessary Perfectionism
  • Motivates Closure
  • Improves Predictability

Short Duration

  • Ease of Planning
  • Fast Feedback
  • Improved Return on Investment
  • Bounded Error
  • Rejuvenated Excitement
  • Frequent Checkpoints

Consistent Duration

  • Cadence Benefits
  • Simplifies Planning

No Goal-Altering Changes

What Is a Sprint Goal?

Each sprint can be summarized by a sprint goal that describes the business purpose and value of the sprint. Typically the sprint goal has a clear, single focus, such as

  • Support initial report generation.
  • Load and curate North America map data.
  • Demonstrate the ability to send a text message through an integrated software, firmware, and hardware stack.

During sprint planning, the development team should help refine and agree to the sprint goal and use it to determine the product backlog items that it can complete by the end of the sprint.

Mutual Commitment

Change versus Clarification

What constitutes a change? A change is any alteration in work or resources that has the potential to generate economically meaningful waste, harmfully disrupt the flow of work, or substantially increase the scope of work within a sprint. Adding or removing a product backlog item from a sprint or significantly altering the scope of a product backlog item that is already in the sprint typically constitutes change.

Clarifications are additional details provided during the sprint that assist the team in achieving its sprint goal.

Consequences of Change

Let’s say we want to swap out feature X, currently part of the sprint commitment, and substitute feature Y, which isn’t part of the existing commitment. Even if we haven’t started working on feature X, we still incur planning waste. In addition, feature X might also have dependencies with other features in the sprint, so a change that affects feature X could affect one or more other features, thus amplifying the effect on the sprint goal.

If work on feature X has already begun, in addition to the already-mentioned waste, we could have other potential wastes. For example, all of the work already performed on feature X might have to be thrown away. And we might have the additional waste of removing the partially completed work on feature X, which we may never use in the future (we’re not going to include partially completed work in a potentially shippable product increment at the end of the sprint).

And, of course, if feature X is already completed, we might have wasted the full investment we made in feature X. All of this waste adds up!

The Definition of Done

the definition of done

Often I am asked, “What if there is a significant defect that remains on the last day of the sprint; is the product backlog item done?” No, it’s not done! And because, as a rule, we don’t extend sprints beyond the end of the planned timebox, we wouldn’t extend the sprint by a day or two to fix the defect in the current sprint. Instead, at the planned end of the sprint, the incomplete product backlog item is taken from the current sprint and reinserted into the product backlog in the proper order based on the other items that are currently in the product backlog. The incomplete item might then be finished in some future sprint.

Requirements and User Stories

product backlog over time

What Are User Stories?

User stories are a convenient format for expressing the desired business value for many types of product backlog items, especially features. User stories are crafted in a way that makes them understandable to both business people and technical people. They are structurally simple and provide a great placeholder for a conversation. Additionally, they can be written at various levels of granularity and are easy to progressively refine.

The CCC approach – Card, Conversation, Confirmation


The card idea is pretty simple. People originally wrote (and many still do) user stories directly on 3 × 5-inch index cards or sticky note. A card should hold a few sentences that capture the essence or intent of a requirement. It serves as the placeholder for more detailed discussions that will take place among the stakeholders, product owner, and development team.


The details of a requirement are exposed and communicated in a conversation among the development team, product owner, and stakeholders. The user story is simply a promise to have that conversation. The conversation is typically not a one-time event, but rather an ongoing dialogue. Most of the conversations lead to creation of documents and UI sketches.


A user story also contains confirmation information in the form of conditions of satisfaction. These are acceptance criteria that clarify the desired behavior. They are used by the development team to better understand what to build and test and by the product owner to confirm that the user story has been implemented to his satisfaction.  If the front of the card has a few-line description of the story, the back of the card could specify the conditions of satisfaction

Level of Detail

user story abstraction history


The largest would be stories that are a few to many months in size and might span an entire release or multiple releases. Many people refer to these as epics. We would never move an epic into a sprint for development because it is way too big and not very detailed. Instead, epics are excellent placeholders for a large collection of more detailed stories to be created at an appropriate future time.


The next-size stories in Figure 5.5 are those that are often on the order of weeks in size and therefore too big for a single sprint. Some teams might call these features.


The smallest forms of user stories are those I typically refer to as stories. To avoid any confusion with epics, features, or other larger items, which are also “stories,” some people call these stories either sprintable stories or implementable stories to indicate that they are on the order of days in size and therefore small enough to fit into a sprint and be implemented.


Some teams also use the term theme to refer to a collection of related stories. Themes provide a convenient way to say that a bunch of stories have something in common, such as being in the same functional area.


Tasks are the layer below stories, typically worked on by only one person, or perhaps a pair of people. Tasks typically require hours to perform. When we go to the task layer, we are specifying how to build something instead of what to build (represented by epics, features, and stories). Tasks are not stories, so we should avoid including task-level detail when writing stories.

INVEST in Good Stories

  • Independent – As much as is practical, user stories should be independent or at least only loosely coupled with one another.
  • Negotiable –  When stories are negotiable, developers can’t really say, “Hey, if you wanted it, you should have put it in the document,” because the details are going to be negotiated with the developers. And the business people can’t really say, “Hey, you obviously didn’t understand the requirements document because you built the wrong thing,” because the business people will be in frequent dialogue with the developers to make sure there is shared clarity. Writing negotiable stories avoids the problems associated with up-front detailed requirements by making it clear that a dialogue is necessary.
  • Valuable – Stories need to be valuable to a customer, user, or both. Customers (or choosers) select and pay for the product. Users actually use the product. If a story isn’t valuable to either, it doesn’t belong in the product backlog.
  • Estimatable
  • Small (sized appropriately)
  • Testable –  Stories should be testable in a binary way—they either pass or fail their associated tests. Being testable means having good acceptance criteria (related to the conditions of satisfaction) associated with the story.

Nonfunctional Requirements


As a user I want an interface in English,
a Romance language, and a complex language
so that there is high statistical likelihood
that it will work in all 70 required

Web Browser Support
System must support IE8, IE9, Firefox 6,
Firefox 7, Safari 5, and Chrome 15.

Knowledge-Acquisition Stories

Sometimes we need to create a product backlog item that focuses on knowledge acquisition. Perhaps we don’t have enough exploitable knowledge about the product or the process of building the product to move forward. Such exploration is known by many names: prototype, proof of concept, experiment, study, spike, and so on.

Gathering Stories

How do user stories come into existence? Traditional approaches to requirements gathering involve asking the users what they want. A better approach is to involve the users as part of the team that is determining what to build and is constantly reviewing what is being built. To promote this level of participation, many organizations prefer to employ user-story-writing workshops as a principal means of generating at least the initial set of user stories. Some also employ story mapping to organize and provide a user-centered context to their stories.

User-Story-Writing Workshop

The goal of a user-story-writing workshop is to collectively brainstorm desired business value and create user story placeholders for what the product or service is supposed to do.
The workshop frequently includes the product owner, ScrumMaster, and development team, in conjunction with internal and external stakeholders. Most work- shops last anywhere from a few hours to a few days.

Story Mapping

Story mapping is a technique popularized by Jeff Patton (Patton 2009) that takes a user-centric perspective for generating a set of user stories. The basic idea is to decompose high-level user activity into a workflow that can be further decomposed into a set of detailed tasks.

Patton uses terms like activity, task, and subtask to describe the hierarchy inside a story map. To be consistent with the terminology I introduced earlier, I use epic, theme, and sprintable story.

At the highest level are the epics, representing the large activities of measurable economic value to the user—for example, the “Buy a Product” epic.

Next we think about the sequence or common workflow of user tasks that make up the epic (represented by themes—collections of related stories). We lay out the themes along a timeline, where themes in the workflow that would naturally occur sooner are positioned to the left of the ones that would occur later. For example, the “Search for Product” theme would be to the left of the “Manage Shopping Cart” theme.

story map

Each theme is then decomposed into a set of implementable stories that are arranged vertically in order of priority.

Story mapping combines the concepts of user-centered design with story decomposition. Good story maps show a flow of activities from the users’ perspective and provide a context for understanding individual stories and their relationship to larger units of customer value.

You may also like...