Sprint, Requirement,

and User Stories

“Build software like marathon. You have to running fast
against dateline” – Saka Heroji
Sprint Skeleton Overview
 Sprint Timeboxed Benefit

Established a WIP limit

Forces prioritization

Demonstrate progress

Avoid unnecessary perfectionism

Motivates closure

Improves predictability
 Short Duration Benefit

Ease of planning

Fast feedback

Bounded Error

Improved return of investment

Rejuvenated excitement

Frequent checkpoints
 Consistent Duration might change if..

You are considering moving from four-week sprint to two-week sprint

in order to obtain more frequent feedback but want to try a coupe of
two-week sprints before making a final decision

The annual holidays or end of the fiscal year make it more practical to
run a three-week sprint than the usual two-week sprint

Product release occur in one week, so a two-week sprint would be

wasteful
 Cadence Benefit
Sprints of the same duration provide us with cadence—a regular,
predictable rhythm or heartbeat to a Scrum development effort.

Having a short sprint cadence also tends to level out the intensity of
work

Sprinting on a regular cadence also significantly reduces coordination

overhead

With fixed-length sprints we can predictably schedule the sprint-

planning, sprint review, and sprint retrospective activities for many
sprints at the same time

Finally, if we have multiple teams on the same project, having all

teams with a similar sprint cadence allows for synchronization of the
work across all of the teams
 Sprint Goal

An important Scrum rule states that once the sprint goal has been
established and sprint execution has begun, no change is permitted
that can materially affect the sprint goal.

Sprint Goal Example:

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
 Sprint Abnormal Termination
Sprint termination is used when an economically significant event has
occurred, such as a competitor’s actions that completely invalidate
the sprint or product funding being materially changed.

If a sprint is terminated, the Scrum team will have to determine the

length of the next sprint:

Stay with the original sprint length

Make the next sprint just long enough to get to the end date of
the terminated sprint.
Make the next sprint bigger than a normal sprint to cover the
remaining time in the terminated sprint plus the time for the
next full sprint
Sprint Abnormal Termination
 Definition of Done

Shipping is a business
decision that often
occurs at a different
cadence; in some
organizations it may
not make sense to
ship at the end of
every sprint
 Specific Item depend on checklist

The nature of the product being built

The technologies being used to build it

The organization that is building it

The current impediment that affect what is possible

 Definition of Done Can Evolve Over Time

or many high-performance teams, the target end state of the work

enables it to be potentially shippable

End state remains relatively constant over the development lifecycle

Many teams, however, start out with a definition of done that doesn’t
end in a state where all features are completed to the extent that they
could go live or be shipped

The product increment is composed of a set of product backlog items, so

each backlog item must be completed in conformance with the work
specified by the definition-of-done checklist
Scrum uses placeholders for requirement
 User Stories Card

A common template format for writing user s to specify a class of users

(the user role), what that class of users wants to achieve (the goal), and
why the users want to achieve the goal (the benefit)
 User Story with additional data
(Conversation)

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.
 User Story conditions of satisfaction
(Confirmation)

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
User Story Abstraction Hierarchy
User Story Guidance Independent

Negotiable
Valuable
Estimable

Estimable

Size Appropriately

Testable

Nonfunctional
requirement
Story Mapping
• Kenneth S. Rubin (2013), Essential Scrum: A
Practical Guide to the Most Popular Agile
Process. OOPE. New Jersey. ISBN: 007-
6092046028