Dive into Scrum - Accelinnova · pen while in Zero gravity > So that < I can record key information that I might otherwise forget > Epic Example NASA specified and developed,

Dive into Scrum …

Scrum Overview

Roles

User Stories

Estimating

Planning

Information

Radiator

Sprints

Scrum

Release

Backlog

Scrum on a Page

Roles

Product Owner

ScrumMaster

TeamStakeholders

Artifacts

Meetings

Product

Backlog

Release

Backlog

Sprint

Backlog

Blocks

List

Information Radiator

Sprint

Planning

Daily

Scrum

Sprint Review

Meetings

Concept inspired by William Wake’s “Scrum on a Page,” http://xp123.com/xplor/xp0507/index.shtml

ReleasePlanning

ProductPlanning

Scrum Roles

DefinitionsWho does what?

Stakeholders

Anyone who

can give input

to the business

objectives of

the product.

Types of Stakeholders

Principals Champion the need for your software and

have the authority to acquire and deploy it.

End Users Personally interact with your software.

Partners Make your product work in real life, such

as operations teams and also business

partners and system integrators.

Insiders Are in your own organization; such as

developers, support engineers, sales,

architecture, and marketing teams.

Product Owner

Builds the roadmap and prioritizes features in

collaboration with:

Business Leaders

Stakeholders

Scrum Master

Functional representatives from the team

Get inside

consumer’s mind

Outside In Development

Understand your stakeholders

Align with stakeholder goals

Define success in your stakeholders’ terms

Understand organizational context

Make products consumable

The customer is always moving, changing,

and if you’re not out there all the time trying

to understand the functional and emotional

needs of consumers, your design will simply

fall flat.

- Matthew May

““

Handles “blocks” outside of the team

Co-ordinates with other Scrum Masters when needed

Removes barriers between the delivery team and the customer so customer directly drives development

Facilitates creativity and empowerment

Improves productivity of delivery team in any way possible

Facilitates improving engineering practices and tools so each sprint is ready to deploy

Scrum Master

Is not a project manager

(Team manages itself)

Does not have authority over the team

(Team makes decisions)

Always asks the question:

“How are the Product Owner and the Team doing?”

Challenges the organization,

Plays a key role in the change

Scrum Master

Team

Add self organizing and ownership bits here.Teams

Unleashing Innovation

Collaboration Process

Exercise

1. Form pairs

2. Assign one as boss, the other as worker

3. The boss can give the following commands:

Go, Stop, Right, Left, Faster, Slower

4. The worker must follow the boss’s

commands

5. Goal: 60 steps in two minutes, circle the

room at least once

6. The boss can command the worker, but

can’t touch the worker

Quick Exercise (A)

1. Everyone is a worker and responsible for

figuring out how to proceed during the

exercise

2. Goal: 60 steps in two minutes, circle the

room at least once

Quick Exercise (B)



Exercise

Retrospective

Leadership, management, and team

involvement very different:

Encourages a collaborative

environment

All roles support one another

Everyone stands and falls

together

“Self Directed” or “Self Organizing”

stakeholdersmarketing

salesline of business

delivery team

( dev & test & …)

architecture

support

Whole Team Concept

When you're in a ‘trusted’ environment,

teams tend to innovate better, more

quickly and overall transaction costs are

much lower.

“ “Sue McKinney

Create a Trusting Environment

Command &

Control

Team Does as Instructed

No Ownership

Leader / Process

is Bottleneck

Conflict

Team Demotivated

Mired in Bureaucracy

& Wasted Effort

Energy &

Innovation

Team Trusted

Team Accountable

Leader Freed

Failure

No One Cares

HighTeam/Individual Ownership

Control

Trust

Low

Lea

de

rsh

ip

& B

usin

ess P

rocess

Trust and Ownership Model

Leader’s View

The team won't let me down

The team understands what we need

They will do the right thing

They will tell me if they need help

Requires a Trusting Environment

Individuals within the Team

We understand the vision and the need

We are jointly committed to meeting our

goals

We stand or fall together

We have ownership

Requires a Trusting Environment

The Team

Step Up

Make & Meet Commitments

Deliver Real Value

Actively Improve

Support Other Teams

Ask for Help when you need it

Demonstrate Ownership / Build Trust

Individuals within the Team Take Active Part Planning ( Release & Sprint )

Scrum Meeting

Demo

Reflection

Be Honest Open Straightforward Respectful

Step Up

Make & Meet Commitments to Each Other

Hold Each Other Accountable

Help Each Other

Coach / Challenge Loafers

Demonstrate Ownership / Build Trust

Whole Team: Involved but not personally

committed to delivery May be involved in planning

& retrospectives May observe daily standups

Delivery Team: Committed to delivery Active participants in planning &

retrospective Active participant in daily

standup

Whole Team

Delivery Team

Whole Team and Delivery Team

Takes ownership of delivery

Identifies and removes obstacles

Estimates the “bigness” of the user stories

Decides what stories should be completed in the sprint

Delivers “done, done, done” stories

Keeps technical debt low

Helps each other succeed

Holds each other accountable

Improves their process

Delivery Team Does What?

Responsible for continuous innovation

during the release

Consists of:

Product Owner

Architect

UX Developer

Discovery Team

Business Owner

Stakeholder

Product Owner 80%

Interaction Designer 20%Developer / Arch 20%

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint n

Continuous Innovation

Product Owner 20%

Interaction Designer 80%Developer / Arch 80%

Discovery Team

Dev

Product Owner

Discovery TeamProduct Manager

Product StrategyProduct RoadmapLaunch Readiness

Product Backlog Release Backlog

Drives Continuous Innovation on Project

Sprint Backlog

Scrum Master, Developers and Testers

Development Manager

UnblockingResource Management

ArchitectUX Developer

Delivery Team

Program Manager

Agile ReadinessRisk, Dependency and

Interlock Mgmt

Agile Organizational Structure

Definitions

Roles

Summary

Stakeholders: give input on the product

business objectives

Product owner: facilitates understanding

and prioritizing based on business value

Scrum Master: ensures that the team is

functional and productive

Team: self-organizes to get the work done

Roles in a Nutshell

Your

Questions?

Scrum Roles

Agile Planning

Why plans go wrong…

Lateness passed down schedule

• Task 3 late when?

• Have you ever started a term paper the night before it was due?

Student syndrome

• It is based on estimates like this:

Student syndrome

Task Local Safety

• It is based on estimates like this:

• But we do this:

Student syndrome

Task Local Safety

TaskLocal Safety

• 20-30% time increase to do each task

• Greater loss on complex tasks

Multitasking

Task 1 Task 2 Task 3

1 2 31 2 3 1 2 31 2 3 1 2 31 2 3 1 2 31 2 3

To do two things at

once is to do neither.- Publilius Syrus

The Effects of Multitasking

Short Planning Cycles - Immediate Action

• Rapid Releases

• Iterations – every 2 weeks

• Scrum Meeting Daily

• Tasks < 16 hours

How does Agile help?

What’s a good plan?

“It is a bad plan that admits to no modifications.”

-- Publilius Syrus (ca. 42 BCE)

Project Management

What’s a Good Plan?

Supports reliable decision-making

Goes from:

Will be done in fourth quarter

… in November

…. November 7

Or:

We want to have all of this

… This is the most important

… We can go to market with this

A Plan is NOT a Commitment

It is a current view.

If one sticks to the idea that once set, a plan should not be changed, a business cannot exist for long.

--- Taiichi Ohno

In preparing for battle I have always found that plans are useless, but planning is indispensable.

--- Dwight D. Eisenhower


• If plans were commitments, then we are committing to decisions made when we were the most ignorant (recall the cone of uncertainty, 5%)

Measuring conformance to plan is measuring the wrong thing because the plan will change


What makes planning Agile?

More focused on planning than the plan

Encourages change

Plans are easily changed

Done throughout the project

Where’s my plan?

In the form of three backlogs:

Product BacklogThemes and Epics for Product

Release BacklogRelease Themes, Epics, and User Stories

Sprint BacklogUser Stories and Tasks planned for the Sprint (iteration)

What’s an Agile plan?

Your

Questions?

Agile Planning

Product Planning

Product Planning

Product Backlog:

Develop Release Themes

Develop Product Epic User Stories

Categorize Product Epics by Release Themes

Prioritize based on Business Value

Place Epics into releases

Who: Stakeholders, Business and Team

What’s a Theme?

What are Themes?

Release themes are based on business

objectives

Themes should embody highest business

value needs of the stakeholders and the

product

Focus on stakeholder success

Focus on product welfare: reduce

technical debt, increase maintainability,

etc.

Why Create Themes?

Provide a common goal for the “whole

team”

Used to provide focus for a release

Used to prioritize and de-prioritize work

A well-known release theme provides a

vision to team

Product Theme Examples

Galapagos Themes:

No Unprotected Data

Appliance Scalability

Performance

New Platforms

Your Themes?

What’s a

Product Epic?

Product Epic

Product Epics capture stakeholder goals for

release themes.

They fit into product releases

Will not likely fit in an iteration

Team has an idea of how large the effort is

Create Product Epics with Stakeholders

All the Product Epics form the product backlog.

A concise, written description

of functionality that will be

valuable to a stakeholder.

As a <role>,

I want <goal>

so that <business value>

What is a Product Epic ?

Epic Roles

As a <role>,

I want <goal>


Avoid “the user” as different stakeholders

have different needs

Use roles so that you do not “miss” epics

Teams may develop a set of user roles to

help define relevant epics (personas)

Uer

Principals Stakeholders who champion the need for your

software and have the authority to acquire and

deploy it.

End Users Stakeholders who personally interact with your

software.

Partners Stakeholders who make your product work in

real life, such as operations teams and also

business partners and system integrators.

Insiders Stakeholders within your own organization; such

as developers, support engineers, sales,

architecture, and marketing teams.

Don’t focus only on the end-user role.

Consider other stakeholder types as well.

Epic Roles

Epic Goals

As a <role>,

I want <goal>


Goal is “what the role can do”

Valuable to a stakeholder

Doesn't say “how”, but “what”

Epic Business Value

As a <role>,

I want <goal>


Justifies the value of the epic

Clarifies why a feature is useful

Can influence how a feature should function

Helps prioritize the epic in the backlog

Can lead to other useful features that

support stakeholder’s goals

Example: NASA Epic

As an < astronaut >

I want to < write easily with a ball point

pen while in Zero gravity >

So that < I can record key information that I

might otherwise forget >

Epic Example

NASA specified and developed, at great

expense, a ball point pen that Apollo

astronauts could use in space where gravity

would not make the ink flow.

Russian cosmonauts used crayons.

Moral: specify what you want to achieve,

not how to achieve it.

Example

Theme: Appliance Scalability

Epic:

As a Backup Admin, I want to store my

backup images on a single high-capacity

appliance so that …

What is the business value for this product epic?

Example

Theme: No unprotected data

Epic:

As an IT admin I can readily discover my

unprotected data

So that …..


Example

Theme: New Platforms

Epic:

As an IT Exec, I want to NBU to backup all

my data regardless of backup system or

application type so that …..


Start Up

Exercise: Pick a project.Practicum

Pick a project

Select a Product Owner

Identify themes for your product

Write 1-2 epics for your product

As a <role>,

I want <goal>


Create a Product Backlog

H

H

M

M

M

L

Input Opportunities andIdeas

Output Prioritized Product Backlog(Themes and Product Epics) marked as differentiating or parity

Who Business, Product Owner, Dev Team representatives

Product Planning

Opportunities

& IdeasProduct

Backlog

Your

Questions?

Product Planning

Release Planning

Release Planning

Understand the target release: Themes and decision filters Product epics

Release Backlog Epics: If needed, break product epics to create release epics Prioritize release epics by business value Mark epics as Differentiating or Parity


Release Planning, part 1

H

H

M

M

M

L

Input Product Backlog

Output PrioritizedRelease Epics marked asdifferentiating or parity

Who Business, Product Owner, Delivery Team


Product Backlog

Release

Backlog

Theme

H/D

H/P

H/P

H/D

H/P

M/D

M/P

M/PM/P

M/D

M/P

M/P

L/P

L/D

Galapagos Release Epics

Product Epic:

As a backup admin, I want to protect more

data faster to meet my business SLAs.

Release Epic:

As a NBU admin, I want to run NetApp

NDMP full back-up as fast as the

Incremental so that I can meet my SLAs.

Galapagos Release Epics

Product Epic:

As a Delivery Team Member, I want my

tests to be automated and coverage

measured so that I can deliver software with

quality and speed.

Release Epic:

As a developer I want to automate smoke

tests in Oracle DB Agent so I can make

future changes confidently.

Start Up


For your project

With your Product Owner

Write 2-3 release epics for your one of your

product epics

As a <role>,

I want <goal>


Create Release Epics

Release Planning

Release Backlog:

Develop User Stories for all Epics

User story must fit into a sprint



Release

Backlog

Theme

M/D

M/P

M/PM/P

Release Planning Meeting 2Release Planning, part 2

Input Prioritized Epics

Output User stories for release epics


H/D

H/P

H/P

H/D

How long is the sprint?

How do we decide?

Sprint Duration

How long can

you keep

business

changes out of

the sprint?

Sprint Duration

Leading Agile

Collaboration Model


User StoriesUser Stories

What does a

user story look like?

What is a User Story?

Same format as an Epic.

As a <role>,

I want <goal>


Create a Product Backlog

Select a Product Owner

As a team, identify the release themes for

your project

Write 1-2 epic user stories for each release

Breaking epics

into smaller stories

Creating User Stories

Epic User Stories decompose into smaller User

Stories

Break epics one release at a time for the highest

value epics only

User Stories by definition fit into an iteration

User Stories form the Release Backlog

Avoid user stories that are too small:

• When documenting the story takes longer than

implementing it

• Bugs, user interface tweaks, etc.

Splitting on Operational Boundaries

First Iteration: Basic User Interface

50% of search fields

Parts of query builder that used those fields

Message “search found 297 matches”

Second: Data display grid

Third: Remaining search fields

Remainder of query builder

Search Screen

Fields

Complex Data

Display GridData-

base

Query

Builder

Splitting on CRUD operations

As a technical marketing rep, I can add (create) an

orderable part to the online catalog

As a technical marketing rep, I can view (read) the list

of orderable parts in the online catalog

As a technical marketing rep, I can edit (update) an

orderable part in the online catalog

As a technical marketing rep, I can remove (delete)

orderable parts from the online catalog

CREATE READ UPDATE DELETE

Galapagos Example

Theme:

Automation

Product Epic:

Parity: As a Delivery Team Member, I want

my tests to be automated and coverage

measured so that I can deliver software with

quality and speed.

Galapagos Example

Release Epic:

As Release Stakeholder, I want to access

accurate summarized code coverage

baseline data so I can be properly informed.

User Stories:

As a Team Member, I want an automated

collection of code repository data so I have a

baseline.

Galapagos Example

More User Stories:

As a release Stakeholder, I want to collect

test suite data so I have a baseline against

which to validate.

As an Engineer, I want code coverage

baseline info stored in a location so I can

make use of it.

User Stories Recommendations

Do not maintain a hierarchy of stories under

an epic.Easier to manage a flat list of user stories.

Hierarchical stories overcomplicate the

backlog.

Hard to complete.

The epic is not complete just because the

stories are complete.

User Stories Tips

Successful sprints have multiple small

stories:

Smaller stories can be implemented &

tested progressively throughout the sprint

Reduces the time between code and test

Attributes of a Good User Story

Attribute Explanation

Independent Does not depend on other stories

Negotiable Not all details necessary

Valuable Has tangible value to stakeholders of the software

Estimate-able You can estimate stories via story points

Small Fits in an iteration by definition

Testable Required to demonstrate that story is “done”

INVEST ( From Mike Cohn)

Consider ‘Testability’

Format:

Given <Precondition>

When <Action>

Then <Result>

Example:

Given: User account exists in system

When: User enters existing user name and

incorrect password

Then: System displays: “You provided an incorrect

password”

Start Up


For your project

Create a Release Backlog

For ONE release epic:

On 3x5 Sticky Notes:

Decompose your release epic into User Stories

One User Story on one sticky note

Do they all pass INVEST?

Prioritize based on:

User stories of highest business value to

stakeholders

Risky user stories for development (technology

challenges, size of work required, etc.)

Installation

Working installer early in cycle allows all teams to move

faster.

Migration

Often difficult to build, and is usually critical to customers.

Prioritize Your Release Backlog

References

Writing Good User Stories:

http://www.extremeplanner.com/blog/2006/0

1/writing-good-user-stories.html

User Stories Applied, by Mike Cohn

Release Planning

Your

Questions?

Agile Estimating

Special thanks to

Mike Cohn,

founder of Mountain Goat Software, who gave us permission to use this material.

mountaingoatsoftware.com

720-890-6110

…. to read the latest Harry Potter book?

…. to drive to Austin, TX?

Exercise: How long will it take …

Size Calculation Duration

300

kilograms

Velocity

=

20

300/20=

15

iterations

Estimate Size by Deriving Duration

Measure of Size

Traditional Measure of Size

Traditional measures of size:

Lines of Code

Function Points

Agile Measure of Size

Agilemeasures of size:

Story Points

Agile Measure of Size

Story Points

The “bigness” of a task

Points are unit-less

Influenced by

• How hard it is

• How much there is

As a buyer, I want to be able to have some but not all items in my cart gift wrapped.

8

Story Points

Relative values are what is important:

• A login screen is a 2.

• A search feature is an 8.

Basic math properties hold, e.g., 5+5 = 10

As a mailer, I want to produce discounted mailings for 1st

class automation letters and flats 30

RhinocerosGiraffe

PigTigerBear

ElephantHorseWolf

Assign “animal points” to capture the bigness of:

Exercise: Animal Points

Exercise: Dog Points

Assign “dog points” to the following breeds: Labrador Retriever

DachshundGreat Dane

TerrierGerman Shepherd

PoodleSt. Bernard

Bulldog

Why Story Points

• Help drive cross-functional behavior

• Estimates do not decay

• Pure measure of size

• Estimating is typically faster

Estimating Tips and

Techniques

Estimate by Analogy

Compare one user story to another

• “This story is like that story”

Don’t use a single gold standard

• Triangulate: Compare the story to be estimated to other estimated stories

Triangulation

Compare a story to similar stories

Group like-sized stories

1 pt

2 pts

3 pts

5 pts

Triangulation

Story A

Story E

Story D

Story H Story J Story K

Story C Story F

Story B Story G Story I

Breaking a big story into smaller stories

• Can’t estimate the big story – don’t know enough

• Break into smaller estimatable stories

Don’t get too small

• Small errors can add up

• Tasks slip through cracks

Disaggregation

How much effort?

A little effort helps a lot

A lot more effort only helps a little

How much effort?

Use the Right Units

Can you distinguish a 1-point story from a 2?

Can you distinguish a 17 from an 18?

Use units that makes sense, such as

• 1, 2, 3, 5, 8, 13

• 1, 2, 4, 8Use Planning Poker Cards

An iterative approach to planning:

Team members use planning poker cards to make an estimate

Product owner reads and discusses a story

Each team member selects a card that’s her estimate, placing it face down

When all cards are face down, turn them over

Outliers are discussed

Continue estimating and discussing until consensus reached

Planning Poker

Estimator Round 1

Susan 3

Vadim 8

Ann 2

Chris 5

Planning Poker Example

Estimator Round 1 Round 2

Susan 3 5

Vadim 8 5

Ann 2 5

Chris 5 8


Estimator Round 1 Round 2 Round 3

Susan 3 5 5

Vadim 8 5 5

Ann 2 5 5

Chris 5 8 5


Come to a value that representsthe group-balanced view

It’s not a competition

3 votes is usually enough

Precision is an illusion

The Goal is Consensus

Exercise: Agile Estimating

Item # Product Backlog Item Estimate

1 Read a high-level 10-page overview of agile software development in People magazine.

2 Read a densely written 5-page research paper about agile software development in an academic journal.

3 Write the product backlog for a simple eCommerce site that sells only clocks.

4 Recruit, interview, and hire a new member for your team.

5 Create a 60-minute presentation about agile estimating and planning for your co-workers.

6 Wash and wax your boss’ Porsche.

7 Read a 150-page book on agile software development.

8 Write an 8-page summary of that book for your boss.

Planning Poker Rules

Only delivery team members estimate their user stories

Outliers explain their estimates

Everyone’s opinion is heard

It’s a conversation! Not a commitment.

Planning Poker Guidelines

Estimate Story Points on all User Stories for ONE release epic.

Who: Delivery Team

Release Planning, part 3Release Planning Part 3

References

Refer to Mike Cohn’s book for details on how to estimate and plan.

Your

Questions?

Agile Estimating

Release Activities

Using Story Points

Velocity

Long-term measure of work completed in

iterations

A GUIDE not a goal.

Track Velocity Multiple Ways

Last Observation=36

Mean (last 8)=33

Mean (lowest 3)=28

Extrapolate from Velocity

Assume five iterations left

Finish here at lowest velocity: 5x28

Finish here at average velocity: 5x33

Finish here at current velocity: 5x36

How much can

I get by <date>?

Fixed Date ‘Planning’

Determine how many iterations you have

Estimate high and low velocity

Low velocity times iterations = ‘will have’ stories

High velocity times iterations = ‘might have’

All the rest = ‘will not have’

Fixed Date ‘Planning’ Example

12x15

Will have

12x20

Might have

Won’t have

Release Burn Up Chart

Done for sprint results against total release backlog.

0

50

100

150

200

250

300

350

400

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Goal

Plan Velocity

Sto

ry P

oin

ts

Iterations

The Goal

The sum of

points for all

stories

The Plan

What we hope for

before validating

team velocity

Original Plan End Date

Using Story Points – The PlanH

igher

Valu

e

Low

er

0

50

100

150

200

250

300

350

400

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Original Goal

New Goal

Plan Velocity

Actual VelocitySto

ry P

oin

ts

Iterations

Additional Stories

Actual Delivery

Original Plan End Date

New Planned End Date

Using Story Points – Adding to The PlanH

igher

Valu

e

Low

er

0

50

100

150

200

250

300

350

400

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Original Goal

New Goal

Plan Velocity

Actual Velocity

Outlook

Sto

ry P

oin

ts

Iterations

Using Story Points - A Realistic Outlook

Mean Velocity

Hig

her

Valu

e

Low

er

0

50

100

150

200

250

300

350

400

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Original Goal

New Goal

Reduced Goal

Plan Velocity

Actual Velocity

Outlook

Sto

ry P

oin

ts

Iterations

Option End Dates

Using Story Points - What are our Options?

Hig

her

Valu

e

Low

er

Your

Questions?

Release Activities

Sprint Planning

Held at the beginning of a new Sprint

Chaired by the Scrum Master

Attended by all including Key Stakeholders

Update the Product Backlog with new user stories

Select highest priority items in the backlog based on Business Value And Optimization of team resources

Sprint Planning Session

Determine user storiesin sprint

Define “done, done, done”

Team commits

Create an information radiator

Who: Delivery Team

Sprint Planning Session

Format:

Given <Precondition>

When <Action>

Then <Result>

Example:

Given: User account exists in system

When: User enters existing user name and

incorrect password

Then: System displays: “You provided an incorrect

password”

What Does “Testable” Mean?

Create a Sprint Backlog

Team may break down stories into tasks (all tasks must be done to demo User Story)

Creating a Sprint Backlog

As a card holder, I want to

be able to withdraw funds

from my account so I can

have cash available to me

Make a withdrawal with

sufficient funds

Make a withdrawal with

insufficient funds

(exception)

Make a withdrawal when

specified denomination

not available (exception)

Consider:

No showstoppers

All errors that the team has not agreed to

are removed

Code is unit tested, function tested,

system tested, performance tested, tested

end-to-end

A meaningful stakeholder review has

been conducted

Team Defines “Done, Done, Done”

This puts a high premium on:

Valuable, maintained, nested automation

Appropriate coverage (e.g. 80%)

True test-driven development

Avoiding technical debt

Continuous integration

Really understanding what quality looks

like

Can “Done3” Really be Done?

Jeff Sutherland (co-creator of Scrum), said while @ PatientKeeper:

“It took us four years to get done, done, done, done.”

Patientkeeper provides safety critical patient management software

Example: Done4

What does “Done”, “Done”, “Done” , “Done” mean?

It is fully developed

It is fully tested

It has no Severity 1s or 2s

It has been deployed before a release in a client environment

Example: Done4

They ship A major release every 3 months

A minor release every month

And minor updates once a week

Consider the competitors, teams of 600-700 developers and they cannot achieve the work flow Patientkeeper does.

Example: Done4

Your

Questions?

Sprint Planning

Sprint Activities

Information Radiator: provides visibility into the status and risks of the sprint

Daily Scrum: facilitates communication

Demonstration: holds delivery team accountable for its commitments

Reflection: enables delivery team to inspect its work and processes and to adapt

Sprint Activities and Artifacts

Visual representation of progress

Display of:

• Work Planned (Product, Release and Sprint)

• Work in Progress

• Work Done

• User Stories to mitigate risk

• User Stories to gather information to make future decisions



Release

Backlog

Epic:

Sprint 2

WP WIP WD

New User Stories


Release

Backlog

Epic:

Sprint 2

WP WIP WD

New User Stories

BH

AK

CO



Release

Backlog

Epic: WP WIP WD

New User Stories

BH AK

COCO

AK

Sprint 2

ExampleExample: Information Radiator

Burndown ChartSprint Burndown Chart

Daily Standup Scrum Meetings

Daily 15 minute status meeting

Same place and time every day

Chaired by Scrum Master

Attended by entire sprint team

Others can attend

Chickens and pigs (only the deliverers speak)

Daily Scrums

Each team member answers:

What did you do yesterday?

What are you doing today?

What are your blocking issues?

No problem solving!

Leave after 15 minutes!

Daily Scrum Outcome

Records:

Sprint Backlog up to date

Scrum Master updates the blocks list

Demonstration

Held the last day of the sprint

Attended by team

Team demos “done” user stories to stakeholders

Requests feedback

Team holds retrospective Updates the process for the next sprint

Demonstration

Only “Done, Done, Done” working user stories. Ask for attendance from the following:

• Executives• Internal users• Stakeholders• Customers

Early iterations may beunsuitable for customers

Add or update stories onthe Release Backlog

Retrospective

Keep

Drop

Add

Keep? Drop? Add?

What surprised us?

Retrospective

Keep

Drop

Add

Ask the team

Which “sticky note”

they want to work on

in the next sprint?

What process

changes will we make

for the next sprint?

Keep, Drop, Add Decision Filters

Does this

Enable us to deliver more value with our resources?

Keep ownership in the team?

Encourage collaboration & communication?

Enable us to handle change quickly?

Build flexibility and enable last responsible moment decision making?

Reduce technical debt?

Help us deliver faster with shorter cycles?

Remove non-value work?

Help get more feedback from Customers and Stakeholders?

Clearly show honest progress?

Help us learn more?

The Team owns the learning

from the retrospective.

They do not have to share it

with the rest of the

organization.

Your

Questions?

Sprint Activities



Scrum Exercise

Develop a Brochure in a 3-day Sprint

Sprint Planning Meeting -10min Create at least 5 User Stories Identify 2 to 3 Tasks per story

Day 1 8 minute day

Day 2 2 minute Daily Scrum 8 minute day

Day 3 2 minute Daily Scrum Meeting 8 minute day

Demo & Reflection

1009080706050403020100

080706050403020100

020100 080706050403020100

020100 080706050403020100



Scrum Exercise

Retrospective

Protect Team Boundaries

Agile Summary

Scrum

Release

Backlog

Scrum on a Page

Roles

Product Owner

ScrumMaster

TeamStakeholders

Artifacts

Meetings

Product

Backlog

Release

Backlog

Sprint

Backlog

Blocks

List


Sprint

Planning

Daily

Scrum

Sprint Review

Meetings

Concept inspired by William Wake’s “Scrum on a Page,” http://xp123.com/xplor/xp0507/index.shtml

ReleasePlanning

ProductPlanning

H

H

M

M

M

L

Product Planning

Opportunities

& IdeasProduct

Backlog Input Opportunities andIdeas

Output Prioritized Product Backlog(Themes and Product Epics) marked asdifferentiating or parity

Who Business, Product Owner, Dev Team representatives

H

H

M

M

M

L

Input Product Backlog

Output PrioritizedRelease Epics marked asdifferentiating or parity



Product Backlog

Release

Backlog

Theme

H/D

H/P

H/P

H/D

H/P

M/D

M/P

M/PM/P

M/D

M/P

M/P

L/P

L/D

Release

Backlog

Theme

M/D

M/P

M/PM/P



Output Release BacklogUser stories for release epics


H/D

H/P

H/P

H/D



Output Estimated and Prioritized Release Backlog (story points)

Who Delivery Team using planning poker

Release

Backlog

Theme

H/D

H/P

H/P

H/D

5

5

3

8

5

2

5

8

3

1

WP WIP WD

New User Stories

Sprint Planning

Input Release Backlog

Output Sprint Backlog, Definition of Done, Architecture Spike, Information Radiator

Who Delivery Team

Leadership Role

Agile is continuous learning

and adaptive planning.

- M. Buckingham

Leadership Role

A good agile project will build

something that meets customers

needs but may be different from

original plans.

- Jim Collins

References

http://scrumalliance.org/pages/what_is_scrum

Scrum and XP from the Trenches, Henrik Kniberg

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

http://c2.com/cgi/wiki?PairProgrammingBenefits

The Elegant Solution, Matthew May

Outside-in Software Development, Carl Kessler

and John Sweitzer

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

http://c2.com/cgi/wiki?PairProgrammingBenefits

References

Agile Project Management with Scrum, Ken Schwaber(for scrum novices)

Agile Software Development with Scrum, Ken Schwaber and Mike Beedle(for experienced scrum types)

Q&A

Documents

Dive into Scrum - Accelinnova · pen while in Zero gravity > So that < I can record key information that I might otherwise forget > Epic Example NASA specified and developed,