You are on page 1of 78

Agile with SCRUM Overview

and User Stories

Peter Saddington, CSM CSP


Enterprise Agile Coach
Executive Editor
AgileScout.com
@agilescout
Peter Saddington, CSP CSM
Independent Enterprise Agile Coach
Rally Software Agile Coach
Executive Editor AgileScout.com
Author – Scrum Pocket Guide
me@peter.ps
+1.404.669.6662
www.agilescout.com
www.scrumpocketguide.com
Twitter: @agilescout

White Barrel LLC. © 2011 Peter Saddington


Before we begin… A Standup!
Let’s take a moment to introduce ourselves.

•What’s your name & project you’re working on?


•What is your level of experience with Agile?
•What do you hope to learn in this workshop?

Write questions on Sticky notes as they occur to you


and affix them to our Learning Backlog.
White Barrel LLC. © 2011 Peter Saddington
Free Swag = #win!

www.scrumpocketguide.com

White Barrel LLC. © 2010 Peter Saddington


Agile Manifesto
• Individuals and interactions over processes and
tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following a plan www.agilemanifesto.org

White Barrel LLC. © 2011 Peter Saddington


Distilled Principles of Agile Manifesto
• Priority is to satisfy the customer
• Deliver working software frequently
• Business and development work together
• Working software is primary measure of success
• The team regularly reflects on work
• Build projects around motivated people

White Barrel LLC. © 2011 Peter Saddington


Process Frameworks
• Waterfall

White Barrel LLC. © 2011 Peter Saddington


Process Frameworks
• Iterative

White Barrel LLC. © 2011 Peter Saddington


Process Frameworks
• Agile

White Barrel LLC. © 2011 Peter Saddington


Agile vs Scrum vs Other Frameworks
• Agile is a mindset, there are several ways to
implement Agile:
– XP – Extreme Programming
– DSDM – Dynamic Systems Development Method
– Scrum – lightweight team centric processes
– Lean – Manufacturing processes applied to software
– FDD – Feature centric processes

White Barrel LLC. © 2011 Peter Saddington


Scrum
• Scrum is not an acronym, but a strategy in the
game of rugby for getting an out-of-play ball back
into play.

White Barrel LLC. © 2011 Peter Saddington


Exercise – Batch vs Flow
Four volunteers, please!
Round 1
•Each person flips all pennies
•When done with entire batch, pass to next person

Round 2
•Each person flip one penny and pass to next person
•Keep flipping and passing until done

Round 3
•Each table creates their own rules to maximize penny flow/throughput in least
amount of time

White Barrel LLC. © 2011 Peter Saddington


Scrum Rules
• Scrum is a set of rules,
procedures, and practices
• Improve the development
environment
• Reduce organizational
overheads
• Ensure iterative deliverables
match user requirements

White Barrel LLC. © 2011 Peter Saddington


Scrum Approach
• Work together as a whole
team
• Focus on business priorities
• Time box short sprints and
releases
• Commit and deliver value
incrementally

White Barrel LLC. © 2011 Peter Saddington


The Chicken and the Pig – A Story:

• Bacon and Egg Restaurant


• Chickens involved…
• Pigs are committed!

White Barrel LLC. © 2011 Peter Saddington


How It All Starts
• A Scrum project starts with a
vision of the system or product
to be developed
• The vision might be vague at
first…
• Perhaps stated in market terms
rather than system terms…
• But it will become clearer as the
project moves forward
White Barrel LLC. © 2011 Peter Saddington
Scrum Roles
• Product Owner
– The single customer voice who establishes the vision,
prioritizes the work and defines success criteria
• ScrumMaster
– The situational leader who empowers the team,
facilitates the process, and removes impediments
• Cross-functional team
– The people who deliver the customer value

White Barrel LLC. © 2011 Peter Saddington


Scrum Meetings
• Daily Scrum
• Sprint Planning Meeting
• Sprint Review Meeting*
• Demo
• Sprint Retrospective

White Barrel LLC. © 2011 Peter Saddington


Scrum Artifacts
• User Stories
• Product Backlog
– List of functional and non-functional requirements
• Sprint Backlog
– Prioritized list of stories for a given sprint
• Sprint Burndown Chart
– A chart showing completion of stories over time
• Definition of done
White Barrel LLC. © 2011 Peter Saddington
The Bottom Line
• Scrum is:
– Doing the simplest thing
possible
– Getting a team what it
needs and getting out of
their way
– Removing any obstacle
that is preventing a team
from being productive and
efficient
White Barrel LLC. © 2011 Peter Saddington
Final Thoughts
• The core of Agile is the team
• Focus on the priorities first (most valuable)
• Communication
• Document throughout the process instead of all
up front
• Review, review, review
• Define the “done.”

White Barrel LLC. © 2011 Peter Saddington


User Stories – Better Practices

A Quick Guide to Story Creation in


Scrum
Peter Saddington CSM, CSP
Agile Scrum Coach
A Worldview

White Barrel LLC © 2010 Peter Saddington


Roadmap

White Barrel LLC © 2010 Peter Saddington


Why Not Requirements Documents?
Complete specifications:

•Assume everything is knowable in


advance
•Are time-consuming to write and
tedious to read
•Treat learning as a “Change of
Scope”
•Don’t lend themselves to
iterative, incremental delivery
process
White Barrel LLC © 2010 Peter Saddington
User Stories are a Conversation
User stories are:

•User or customer need


•Product description
•Used for planning
•A conversation piece

White Barrel LLC © 2010 Peter Saddington


User Stories Facilitate Conversation
• User* – How do I describe what I want?
• Stakeholder – What do I need in my product to
be successful?
• PM – How do I track and schedule this work?
• BA – What are the details of this feature?
• UX – How do I understand the users needs?
• Developer – What are the details of the tasks I
need to work on today?
• QA – How do I validate this completed work?
Adapted from Jeff Patton www.AgileProductDesign.com

White Barrel LLC © 2010 Peter Saddington


A User Story Is
• Easy to understand – Makes sense to the reader
• A (software/system) requirement
• One or two sentences with value to the customer
• Written by the Customer – PO or BA
• Refined by Development – Tasks and Technical
• Negotiable – Conversation token
• Small and estimable – Small enough to estimate
• Testable – Should have acceptance criteria
• Becomes more detailed over time – Iteration Planning
White Barrel LLC © 2010 Peter Saddington
User Story Process
Step #1 Step #2 Step #3

White Barrel LLC © 2010 Peter Saddington


Step #1 - Where do we start?
Define the user personas!

•What different types of customers/consumers


interact with the system?
•What are their roles?

White Barrel LLC © 2010 Peter Saddington


User Role Modeling
• User Roles
– Various types of user personas
• Role Modeling
– Brain storming
– Organizing
– Consolidating
– Refining
• Extreme Characters?

White Barrel LLC © 2010 Peter Saddington


Exercise - Defining the Personas
Scenario: You need to create a
simple login and preferences
mechanism for your corporate
Twitter account

•Who are your users of this


system?
•What are their roles?

White Barrel LLC © 2010 Peter Saddington


Persona Definition Documentation?

White Barrel LLC © 2010 Peter Saddington


Roadmap

White Barrel LLC © 2010 Peter Saddington


Story Creation - Guidelines
• Stakeholders write user stories
• Remember non-functional requirements
• Indicate the estimated size
• Indicate the priority
• Include a unique identifier (if applicable)
• Go into a product backlog
• The product backlog is prioritized by value –
Highest to lowest

White Barrel LLC © 2010 Peter Saddington


Non-Functional Requirements
• Non-functional requirements should often be
considered “constraints” on a system
• Can include:
– Performance
– Quality
– Accuracy
– Portability
– Reusability
– Maintainability
– Interoperability
– Capacity Adapted from Mike Cohn www.mountaingoatsoftware.com

White Barrel LLC © 2010 Peter Saddington


INVEST Model
• Independent – One user story should be independent of another (as much as
possible). Dependencies between stories make planning, prioritization, and
estimation much more difficult.
• Negotiable – Details of the story can be worked out during an Iteration
planning meeting. A story with too much detail can limit conversations (at
times).
• Valuable – Value to the customer.
• Estimable – There needs to be enough detail for the developers to estimate a
user story to allow prioritization and planning of the story.
• Small – A good story should be small in effort, typically no more than 2-3
person weeks of effort (smaller is better)!
• Testable – User stories should be testable with certain acceptance criteria.
Saying something like “software should be easy to use” is not helpful.

Bill Wake’s INVEST Model

White Barrel LLC © 2010 Peter Saddington


Ron Jeffries 3 C’s
• Card – Stories written on note cards with
annotations as needed (estimates, notes, etc)

• Conversation – Details behind story come out


through conversations with the Product
Owner

• Confirmation – Acceptance tests confirm the


story was coded correctly

White Barrel LLC © 2010 Peter Saddington


Four Main Components of a Story
• (Given (AS A)) – “As a business owner…” / “Given a new list…”

• (When (I WANT)) – “I’d like the ability to…” / “We need a function
to…” / “When a customer clicks on…” / “When a dropdown opens
…”

• (Then (SO THAT)) – “So that I can…” / “So that the customer can…” /
“Then the customer should see…” / “Then the dropdown list
should…”

• (Acceptance Criteria) – Verifiable and testable criteria that can be


tested based on THEN clause.

• Or Simply: “As a <user type>, I want to <function> so that I can


<business value>
White Barrel LLC © 2010 Peter Saddington
1. Given
(Given (AS A)) – “As a business owner…” /
“Given a new list…”
-We want users to be tangible with needs

-Build out “Personas” or “User Roles” – Standard


user definitions (Sacred – Added with purpose)

-Avoid generic terms

White Barrel LLC © 2010 Peter Saddington


2. When
(When (I WANT)) – “I’d like the ability to…” /
“We need a function to…” / “When a customer
clicks on…” / “When a dropdown opens…”

-This is the meat and potatoes of the story

-This is where you describe the functions

White Barrel LLC © 2010 Peter Saddington


3. Then
(Then (SO THAT)) – “So that I can…” / “So
that the customer can…” / “Then the
customer should see…” / “Then the
dropdown list should…”

-This is to show the intrinsic value of the


story

-The value is to the persona, user, or author


White Barrel LLC © 2010 Peter Saddington
4. Acceptance Criteria
(Acceptance Criteria) – Verifiable and
testable criteria that can be tested based on
THEN clause.

-These are essentially tests – Conditions of satisfaction


-Example: As a user, I can cancel a reservation.
- Verify that a premium member can cancel
- Verify that a email confirmation is sent
- Verify that the hotel is notified of any cancelation
-These acceptance criteria can become developer tasks

White Barrel LLC © 2010 Peter Saddington


4a. Acceptance Stories
(Acceptance Stories) – Verifiable and
testable criteria written in acceptance test
form.

-Scenario 1: TITLE
- GIVEN [context]
- And [some more context]
- When [event]
- Then [outcome]
- And [another outcome]

White Barrel LLC © 2010 Peter Saddington


4b. Acceptance Confirmation
(Acceptance Confirmation) – Verifiable and
testable criteria written in “Success” and
“Failure” terms

-Success – valid user logged in


- “Remember my user name” selected – store cookie / automatic login next
time
- “Remember my user name” not selected – force login next time
-Failure – display message:
- “Email address in wrong format”
- “Incorrect password, please try again”
- “Service unavailable, please try again”
- Etc.
White Barrel LLC © 2010 Peter Saddington
Exercise – 99 Balloons
Let’s form some teams!
Round 1
•Recreate my balloon with: 2 round eyes, a triangle nose, and a semi-circle mouth
•2 minutes! Go!

Round 2
•How can you improve for the next iteration?

Round 3
•How did you change how you worked this time around?

White Barrel LLC. © 2011 Peter Saddington


Step #2 – Gathering User Stories
• User Interviews
– Select right interviewees
– Ask open-ended, context-free questions
• Questionnaires
– Larger population of users
– When you need specific answers to questions
• Observation
– Best for in-house developments
• Story writing workshops
White Barrel LLC © 2010 Peter Saddington
Exercise – Refine the User Stories
Scenario: You need to create a
simple login and preferences
mechanism for your corporate
Twitter account

•We’ve determined our


users…
•Let’s refine the set of user
stories
White Barrel LLC © 2010 Peter Saddington
Roadmap

White Barrel LLC © 2010 Peter Saddington


Product Backlog to Release Backlog
• A prioritized list of
features for the given
product
• Stories are implemented
based on their priority
• The TOP priority Features
are put into iterations
first
• Changes to the iterations
are OK
• After stories are built
they go into a release
backlog
White Barrel LLC. © 2010 Peter Saddington
Prioritization Factors to Consider
• Financial value of
features
• Costs of
implementation
• Amount of risk
removed / added
• Training on new
features
• PO should be
enabled
White Barrel LLC. © 2010 Peter Saddington
MoSCoW Method
• M – MUST have (Critical for success)
• S – SHOULD have if possible (If not time
critical)
• C – COULD have if it does not affect
anything else (Include if little development
cost)
• W – WON’T have this time, but WOULD
like in future MoSCoW method - Dai Clegg of Oracle UK for DSDM

White Barrel LLC © 2010 Peter Saddington


M & S of MoSCoW
• M – MUST have (Critical for success)
– Essential - key stakeholders needs will not be
satisfied if this requirement is not delivered and the
timebox will be considered to have failed
• S – SHOULD have if possible (If not time
critical)
– Important - but if not delivered within the current
timebox, there is an acceptable workaround until it
is delivered during the next sprint
White Barrel LLC © 2010 Peter Saddington
C & W of MoSCoW
• C – COULD have if it does not affect
anything else (Include if little development
cost)
– “Nice to have” – this is estimated to be possible to
complete in the timebox but will be de-scoped if an
underestimation has occured
• W – WON’T have this time, but WOULD
like in future
– Will not be delivered within the timebox
White Barrel LLC © 2010 Peter Saddington
Kano’s Model of Quality
Objective and Subjective Quality

•Must-haves – Same as “M” in MoSCoW


•One-dimensional – “The more of this I get,
the better.”
•Delighters – Great to haves
Noriaki Kano – Theory of Product Development

White Barrel LLC © 2010 Peter Saddington


Kano’s Model - Example
• In Agile – Objective quality is non-negotiable
• Subjective quality – Perception of quality
– To accurately assess subjective quality, the Product Owner
MUST know the customers (primary users)
– One user’s “delighter” may leave others apathetic
– One user’s “must have” is useless to others

Jeff Paton – www.Agileproductdesign.com

White Barrel LLC © 2010 Peter Saddington


Prioritization Sliders

White Barrel LLC. © 2010 Peter Saddington


Step #3 – A.C. and Backlog Priority
• Manage the backlog by:
– Sorting stories by user persona
– Sorting stories by highest priority (value)
– Review stories for completeness
– Asking the 4 “WHYs” for business value
• Why do you want…?
– [As a] Customer Service Representative
– [I want] to have a button
– [So that] I can go to the next screen…

White Barrel LLC © 2010 Peter Saddington


Exercise – Stories to Backlog
Scenario: You need to create a
simple login and preferences
mechanism for your corporate
Twitter account

•We’ve determined our users…


•We’ve refined the set of user
stories
•Let’s put A.C. and priority

White Barrel LLC © 2010 Peter Saddington


Roadmap

White Barrel LLC © 2010 Peter Saddington


Themes to Tasks

White Barrel LLC © 2010 Peter Saddington


Tasks Warm Up Exercise
What are all the things you did to get ready to be
at work today?

1.Starting from the moment you woke up to


arriving here.

2.Take a sheet of paper and write them down!

White Barrel LLC © 2010 Peter Saddington


Tasks vs Tools Exercise
1. Share with the group some example lists

2. What are common themes and tasks?

3. What was different?

White Barrel LLC © 2010 Peter Saddington


Goals, Tasks, Tools

White Barrel LLC © 2010 Peter Saddington


User Stories are Tasks or Tools

White Barrel LLC © 2010 Peter Saddington


Stories Satisfy User NEEDS First!

White Barrel LLC © 2010 Peter Saddington


Simple Guidelines for Good Stories
1. Start with specific personas

2. Write closed stories first

3. Write stories collaboratively

White Barrel LLC © 2010 Peter Saddington


Exercise – Creating at a Story
1. Take a current feature your team is aware of

2. Each team member writes the story

3. Share

4. Discuss – Implications / Constraints / Missed AC

5. Review
White Barrel LLC © 2010 Peter Saddington
Roadmap

White Barrel LLC © 2010 Peter Saddington


Epic User Stories
Causes for Story Size
• Stories cover too much information
• Story writers do not have the needed domain
knowledge
• Stories have uncertainty due to dependence on
new technology
• Story writers cannot articulate exactly what
they want

White Barrel LLC © 2010 Peter Saddington


Breaking Up Epics
Split – Slice stories up into different scenarios
Spike – Too many unknowns? Time-box a spike
and take a deep dive into the technology or
domain
Stub – Part of a story known and part unknown.
Fake it with a stub! Work on the known part up
till the unknown.
Time box – The PO knows they need something,
but until they get it, not sure if it’s right
White Barrel LLC © 2010 Peter Saddington
Splitting for Value - Three Rules
When breaking down epics, remember:

1. Split stories for value – No value? Hard to


prioritize
2. Split a story that gets you more equally sized
small stories
3. Split an epic that lets you deprioritize or throw
away a story

White Barrel LLC © 2010 Peter Saddington


Exercise – Breaking Up Epics
Let’s take an example from our existing backlog

White Barrel LLC © 2010 Peter Saddington


Suggestions for Splitting Up Epics
• Handle empty scenarios and core functions first
• Happy path, then alternate flows / exceptions
• Single option, then add additional options
• Simple (or no) UI, then add bells / whistles
• Transient case (no memory between sessions) before
persistence
• Static elements, then dynamic based on content
• User specified, then more automation

White Barrel LLC © 2010 Peter Saddington


Roadmap

White Barrel LLC © 2010 Peter Saddington


Notes on Bug or Issue Tracking
1. Steps to Reproduce / Recreate the Bug

2. Actual Results

3. Expected Results

4. Any other details as appropriate

White Barrel LLC © 2010 Peter Saddington


Exercise – Baseline Story Estimation
1. Different Stories in different sizes (1,2,3,5,8…)

2. What was the estimated size?

3. What were the complexities of that story?

4. Does this story need a re-write? What was missed?

5. Complete for sizes


White Barrel LLC © 2010 Peter Saddington
Questions?

White Barrel LLC © 2010 Peter Saddington

You might also like