Product Backlogs Using User Stories Agile Development & Scrum

Principles and process guide

User stories describe pieces of software to
deliver in the language of someone who

agile
will use the software. A short story title is Capabilities or Stories for upcoming Working tested
written on a card, sticky, or in a list as a
token for conversation. Stories split into Features iterations software
smaller stories and gain more detail over •  Name •  Priority •  Meets the team s definition
time and through many conversations
with contributors in every role.
•  Target customer or user
•  Value
•  UI Design
•  Business rules
of done
Agile Development is nothing new
The origins of agile thinking are as old as software development. What we call
•  Acceptance tests Minimal “Agile Development” today is a contemporary word applied to a process style Agile is a style of process and an umbrella
At minimum a story needs:
•  Concise title Releasable that’s been emerging since the 1970s. term for lots of specific processes
•  Description
Software
•  Acceptance criteria
Waterfall considered risky Crystal
This popular template helps to think
•  Generates value
from its use In his 1970s paper Winston Royce is credited with drawing the
DSDM
through stories from a user and benefits model we commonly think of as the “waterfall model.” But he
(Dynamic Systems Adaptive Software
perspective: Development Methodology)
drew the diagram in a progression on his way to more Development
as a [type of user] sophisticated models. He pointed out that you’ll need

Scrum Extreme
I want to [perform some action] feedback loops between every phase, and feedback all the
so that I can [reach some goal] way from test back to requirements. Royce was trying to

Use this template as a thinking

describe an iterative development cycle, NOT a sequential
process. Programming
tool, not a writing format. Lean Software
Stories without concise titles “I believe in this concept, but the
Development
FDD
become hard to organize, implementation described above is risky and (Feature Driven
Development)
discuss, and prioritize. invites failure.”

Think about who uses the

--Royce it’s
gets this
“Agile” identifies specific
um
software, what they ll do, and
why.
More like a team sport, Scr
e fr
nam paper!
om values and principles
Release-sized stories Small iteration- Validated product
less like an assembly line
In 2001 17 software professionals gathered to discuss what they
had in common. They were concerned about the continued
•  Target release
•  Relative size sized stories part In the 1986 Harvard Business Review paper “The New New growth of formalized waterfall style process. These professionals
•  UI Sketches •  Detailed acceptance tests •  Vetted with stakeholders, Product Development Game,” Takeuchi and Nonaka studied disagreed on specific process, but agreed strongly on the
•  Rough acceptance tests •  Small enough to complete customers, and users values and principles that drive process creation.
a variety of product design teams and found that the most
in a single iterations •  Evaluated for release readiness
successful had derived a process that looked chaotic on the
Scrum was one of those agile processes. Today Scrum has
outside, but was ultimately faster and more effective at
grown in popularity. While teams may identify their process as
creating great products. They compared these teams work-
“Scrum.” the way they work borrows practices from most other
Organize user stories practice to the sport Rugby.
agile processes.
as a map

Visible Progress
“Under the rugby approach, the product
Organize large capabilities The agile manifesto describes the values and
development process emerges from the constant principles that guide process decisions.
roughly in the order users use
them. Decompose them top to interaction of a hand-picked, multidisciplinary
bottom. This makes the backlog team whose members work together from start

Values & Principles

easy to understand and easy to
to finish.” – Takeuchi & Nonaka
Burn
prioritize.
A burn chart makes progress over time visible. A burn down

Guide Process
chart shows work remaining, while a burn up chart shows
work complete. Watching the slope of the curve on the

Charts chart lets us detect early if we re on track to finish all the

scheduled work on time.

The Agile Manifesto: The principles of Agile development Values & Principles
Values describe what s important to individuals,
Iteration
Day
Story Points Story Points Story Points
In Scope Completed Remaining Burn Down Chart Burn Up Chart We are uncovering better ways of The principles of Agile Software Development, written the same time as the
and collectively to an organization.

1 21 1 20 25 developing software by doing it and manifesto, give principles that help guide choices in how we choose to Principles are the rules of thumb we create and
20
helping others do it. Through this work we work. use to make day-to-day process decisions.
2 21 3 18 Stories added
3 21 6 15 have come to value:
1. Working software is the primary 8. Welcome changing requirements,
4 24 8 16 20 measure of progress. even late in development. Agile
5 24 9 15 15
Stories added Individuals and interactions 2. Agile processes promote processes harness change for the
customer's competitive
Your Context
6 24 11 13 over processes and tools sustainable development. The The process you follow needs to
7 19 11 8 advantage.
sponsors, developers, and users take into account your context.
8 18 13 5 15
Stories removed Working software should be able to maintain a 9. Deliver working software
A spreadsheet houses 10
constant pace indefinitely. frequently, from a couple of •  Haw many people are involved?
9 18 15 3 over comprehensive •  How risky is the project?
the daily totals weeks to a couple of months,
10 18 17 1 documentation 3. Continuous attention to technical
with a preference to the shorter •  How time-sensitive is delivery?
excellence and good design •  How difficult is the problem you re
10 timescale.
enhances agility.
5 Customer collaboration 10. Business people and developers
solving?
4. Simplicity--the art of maximizing the •  What does quality mean in your
over contract negotiation must work together daily

Daily
amount of work not done--is context?
Daily, usually at the start of the day,
the team meets for a short planning
Stories removed essential. throughout the project.
5 Responding to change 11. Build projects around motivated
meeting. Keep the meeting less 1 2 3 4 5 6 7 8 9 10 5. The best architectures,
New Knowledge
Standup than 15 minutes. Focus the
discussion on what it will take to
meet iteration goals. 1 2 3 4 5 6 7 8 9 10
over following a plan
That is, while there is value in the items on
requirements, and designs emerge
from self-organizing teams.
individuals. Give them the
environment and support they
need, and trust them to get the
We continue to discover new concepts
and leverage them to create new and

or Daily
6. At regular intervals, the team job done.
the right (below in this case), we value the better practice and tools. For example:
Each person think about: reflects on how to become more
items on the left more (bold and above in effective, then tunes and adjusts its 12. The most efficient and effective
1. What you worked on yesterday •  A system s throughput is only as fast
method of conveying information

Scrum
this case). behavior accordingly. as its slowest step so we use Kanban
2. What you plan to work on today to and within a development
3. What issues you have blocking 7. Our highest priority is to satisfy the style boards to visualize the flow of
You can find the manifesto & principles at: team is face-to-face
them from getting work done customer through early and work and find bottlenecks faster.
conversation.
http://agilemanifesto.org/ continuous delivery of valuable •  Product ideas are hypothetical until
Stories
Task Wall Stories
In Tasks In Tasks
Ready
For Stories
n’t to
software. proven out after delivery so we use
MVP Tests to validate product ideas
before delivery.
Queue goal is
er, the process, but
A task wall is used to Story Tasks Progress Complete Review Done
visualize work in progress e m b
Rem an agile r high-
during the development
cycle. Moving stickies follow istently delive our
ns y
Process & Practices
across the wall helps the to co lity software love. Practices like test-driven development support
qua users
ers and
team coordinate, and values like being able to respond quickly to
signal progress to each custom change, and principles like technical excellence.
other and people outside Processes combine practices that support each
the team. other and are used by different roles.
© 2015, Jeff Patton • jpattonassociates.com Processes help many people coordinate their
activities to accomplish a common goal.
Roles
Dual-Track Development
Discovery Team Discovery work happens continuously alongside development work.
Scrum Master or Coach Product Ownership A product owner leads the discovery
team that includes individuals that
The scrum master focuses on Product owners focus on product have the knowledge and skills to
process success success identify a valuable, usable, and Opportunities drive
feasible product. discovery
The Scrum Master focuses on making sure A single person may have the title “product
Agile processes and Scrum use three super roles that
satisfy the concerns of building the right product, the
the process is working, that everyone
understands and fills their role, that
owner,” but the ideal product owners is a
great leader. Since a successful product
Individuals like lead engineers Discovery Track
product right, and tuning the process so people can collaboration is effective, that visibility is kept must be valuable, usable, and feasible, a
may be part of both discovery Discovery cycles vary in length. They
perform at their best. Traditional software development and delivery teams start with ideas, and end with
high, and that the team keeps focus on the product owner usually leads a small product learning. You may complete several
roles are often mapped to one or more of these super
goals of the current sprint or iteration and ownership team that includes the skills and cycles of discovery in a single week.
roles. product release. roles needed to be successful: Discovery creates
Remember these roles represent concerns we all Product •  Product manager or business
representative Scrum
backlog items for
experiments or
share and not individual people. In healthy agile Ownership •  UX practitioner
Master Development Track software to deliver
teams people will change hats from one role to Build the right •  Engineer, architect, & tester When you use Scrum for
another. product
Scrum Master development, you’ll see the

Process
predictable delivery of working
Help everyone keep the software every 1-4 weeks Delivery results in
process working working experiments
effectively or deliverable
software
The Delivery Team
Team The team focuses on constructing
Build the a high quality product
This starting process builds from the essential Scrum Framework to add practices product right
that wrap the sprint for product discovery, getting to ready, and getting to The team is composed of all the roles and
release. skills necessary to build, test, and document
software of sufficient quality that it could be Daily Scrum
Remember that process isn’t skill. Success or failure is up to the released. This includes: Reflect on what was done

Day
whole team. The right process gives just enough structure for teams •  engineers the prior day
to effectively collaborate. •  architects Plan what to do today
•  testers Raise issues stopping
The smallest cycle of

Product
•  business analysts progress
work – you can’t
•  UI designers
extend this one if you
•  technical writers
don’t finish what you
planned

Opportunity Discovery Product Product Delivery

Backlog Using collaboration, design thinking, and The product delivery team strives for predictable, high quality, delivery.
Ideas to explore, and
problems to solve.
validated learning answer the questions:
1.  What problems are we solving and for
Backlog
Deliverable pieces of a
product or experiment Product Team Story Workshop Sprint Planning Sprint Sprint Review & Customer & Stakeholder Monitor
who? A fixed time-box for delivering
View your 2.  What will customers and users value?
we’d like the team to
build
Planning Product team members
meet with delivery team
The product owner shows
up “ready” with details for software usually 1-4 weeks Retrospective User Product Product Review Released
organization’s 3.  What can users use to reach their goals?
4.  What’s feasible to build given the tools
The product team meets
routinely to discuss
member regularly to work high priority backlog Demonstrate and critique
the working Product Testing Keep progress visible to
stakeholders outside the Software
roadmap not as through story details and items. The team builds Routinely validate the Almost every day take a
and time we have? release progress, select agree on acceptance their plan and commits. done team
fixed items to backlog Discuss the Progress working software with look at metrics , bug
stories for upcoming backlog
deliver, but as ideas criteria items to do doing done items relative to the plan genuine users and reports, and customer
The speed of Build sprints, and plan the work
to explore and discovery is experiments needed to get stories Delivery Team Reflect on the way customers feedback for software
measured by cycle Task Board you’ve already released
validate. ready for the delivery you’ve been working
time of learning. team. Use to routinely (your Process) and
Try to experiment plan and re-plan
Learn Measure opportunities
change it as necessary
and learn several if your solution delivery work
& observe &
times per week. is viable
backlog backlog
items to do doing done items

Artifacts
While discovering, use opportunity
backlog items for high-fidelity Sprint Backlog
The delivery tasks that delivery
prototypes or live-data
prototypes that requires turn backlog items into
team tasks
Potentially Shippable Viable Product Release
working software
development time to create backlog split & refined
backlog
Software Increment Built iteratively and incrementally each sprint,
this is the product that’ll get you the outcomes
item to get
ready items It may take more software to be valuable to you want from the users you’ve targeted.
users, but it had better not require more testing
Artifacts, or things we see and touch. They help make information, and bug fixing
discovery
ideas, and status visible to the whole team. Basic artifacts include team tasks
backlogs, burndown charts, and task boards.
Release Burndown Product Team Task Board Sprint Burndown
If no one uses the artifacts, remove them because they’re Makes release progress visible. How much is Use to routinely plan and re-plan discovery Makes progress visible during this sprint. Are
likely not working. left to build before we can release? work and work to get items ready to deliver. we making progress?

Product Discovery Getting to Ready Sprint Getting to Release Learn after Release
Pull from a backlog of opportunities use discovery work to To help the team move quickly and predictable, your (Iteration or Development Time-box) The team may be confident in what they’ve built, but After the release monitor metrics and scorecards, and
identify the product you should build. product team lead by a product owner must better we’ll need to validate it with customers, users and observe people using your product. Remember, your
Iterations (Sprints in Scrum) are short fixed time-boxes,
understand and describe the details of what to build. usually 1-4 weeks. At the end of each iteration stakeholders. project may be over, but the life of your product has just
•  Understand the business motivation for building the begun.
demonstrate finished, tested, high quality software. While
product •  The product team plans by identifying user stories 1-3 it s critical to keep the software high quality, don t expect •  Take working software out to customers and users to test
•  Understand the customers and users that will use your iterations in advance. The product team identified that it. Is it valuable? Is it usable? The most valuable improvements to your
it to be releasable after early iterations.
product and the problems your product solves for them work they’ll need to do to design and describe the •  Keep progress and user feedback visible to stakeholders.
•  Ideate: consider multiple solutions to solve your product come from observing people using it
software to build. •  The team plans the sprint by working through the details
customer’s problems •  Collaborating with the team using a workshop approach of what they’ll need to build Continue validating the software you’ve today.
•  Iteratively build and test prototypes with your customers to build shared understanding about what to build. •  Keep visibility high during the iteration using a task wall built with customers, users, and
and users Members of the product team and delivery team work or burn chart
•  Use backlog items to develop higher fidelity and live- together to answer these three questions: What exactly •  Keep collaboration high between the product team
stakeholders to avoid surprises at release
data prototypes where you’ll need development work will be build? How will we know when we’re done? and delivery team time.
•  Describe your validated solution using stories in a How will we demonstrate this new software to others? •  At the end of the iteration use a product review to
product backlog you can use to manage the delivery of evaluate the product and discuss the pace of delivery,
your software.
Work together to explore details and or velocity
•  Use a heartbeat retrospective to adjust your process.
Work together to explore details and describe the software you want to build in
describe the software you want to build in the next time-box. Use Sprints to build software, measure, and
the next time-box. learn. Use what you learn to improve your
product, and the way you work.