practical scrum course day 2

Scrum Workshop by Practical Agile is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

Practical ScrumDay IIIlan Kirschenbaum

Agile coach co-founder @ practical-agile

twitter: @_kirschi email: ilan@practical-agile.com

blog: http://fostnope.com/

Exercise

• Our Specially Crafted Feedback Forms

• Agile Practitioners IL

• Lifetime Guarantee

Agenda

• Product owner

• Product backlog

• Planning

• Estimating

• Sprint planning

• Sprint backlog

• Burndown charts

• Daily scrum

• Sprint review

• Sprint retrospective

• Scrum simulation

• Scaling Scrum

Product Owner

Exercise: The painters game

Round 1

Round 2

Round 3

QIt’s possible to transfer information effectively on written documents without much of human contact.

Essential knowledge is lost in every handover and human interaction is needed

to overcome it.

The Product Owner

• The person that represents the customer.

• Should have business knowledge or at least have access to it.

• Has almost no authority over the team in technical aspects.

• Exceptions are non-functional constraints and requirements And the definition of Done.

Role of the PO

• Defines the features of the product

• Defines release dates and content

• Responsible for ROI.

• Prioritizes feature according to value.

• Can change features and priority once every predefined interval.

• Decides what will be worked on in each iteration

• Accepts or rejects results.

Concept Change

• Traditionally throws content “over the fence”– no more!

• Takes an active role throughout the development lifespan.

• Needs to make decisions regarding ROI every sprint.

• The single wringable neck.

Product Backlog

The Product Backlog

• List of features, Technology, issues.

• Items should deliver value for customer.

• Constantly prioritized & Estimated.

• Anyone can contribute.

The Product Backlog

• Visible to all.

• Derived from business plan, may be created together, with the customer.

• Can be changed every sprint!!!

• Customer is not “programmed” to think of everything in advance.

The Product Backlog - Example

Description Estimate Acc. test sprint

As a user I would like to register 3 1

As a user I would like to login 5Show successful

login & Show failing login

As a buyer I would like to make a bid 3 1

As a buyer I would like to pay with a credit card 8 2

As a seller I would like to start an auction 8 2

The Product Backlog - Example

Description Value Estimate Acc. test sprint Wiki link

As a user I would like to register 1200 3 1 www…..

As a user I would like to login 1100 5

Show successful login &

Show failing login1

As a buyer I would like to make a bid

1000 3 1

As a buyer I would like to pay with a credit card

700 8 2

As a seller I would like to

start an auction10 8 2

... …

The Product Backlog

• Can be defined in any way that serves best the PO.

• User stories are recommended for functional requirements.

• Usually contains the fields: ID, area, description, value, estimate, test criteria.

• Common other fields: dependency details, source of item.

• Remember to “KISS” - Keep it simple, stupid sweetheart!

User Stories

• Are not use cases!

• Describe requirements from the user’s POV

• A defined format:As a …. I would like to…. [so that….]

• Should not include too many details.

• Modeled for discussion, to overcome the communication gap.

• Guidelines for a good story are: Independent, Valuable, Properly sized, Testable.

User Stories - Example

• As a customer I want to be able to check my current balance.

• As a manager I would like to be able to see the overall balance of the customers.

• As a manager I would like to see trends in sales.

• As a sales person I would like to have a report of past activity for specific customers.

• As a customer I would like to reprint receipts of past purchases.

Exercise

As a <WHO> I want to <WHAT> so that <WHY>

QIt is possible to “collect” or even “know” all the requirements up-

Requirements evolve as customers and our knowledge increases – based on

experience

Backlog Items Size

• The product backlog items (PBI) become more granular the higher they are in the backlog.

• Usually the PBI starts as very big items (Epics) and are split into smaller sized items.

• It is common that the PBIs for the next 2-3 sprints are split so that:

• 3-5 PBIs fit within a single sprint.

Splitting User Stories

• Different scenarios

• Stubbing\mocking external dependencies

• Splitting across the data model. E.g Support only a subset of attributes

• Splitting across operationsE.g CRUD \ parts of a protocol

Splitting User Stories

• Splitting on results E.g Success and failure scenarios.

• Splitting cross-cutting concernsE.g Logging \ Security.

• Splitting functional & non-functional requirements

Exercise

Backlog Grooming

• Also called backlog refactoring.

• Done by the team and the PO.

• The goal is to have the backlog ready for the sprint planning.

• Grooming = Splitting, clarifying & estimating.

Backlog Grooming

• Usually grooming just enough for 2-3 sprints ahead.

• Recommended to allocate ~5% of sprint time for this task.

• NEVER allow the PO to reach a sprint planning meeting with a backlog not in good shape.

Agile Planning with Scrum

The “Planning Onion”

Iteration

Release

Product

Portfolio

Strategy

Why Plan?

• Reduce risk.

• Reduce uncertainty.

• Gather data to assist in decision making.

• Provide external stake holders with data.

• Establish expectation to measure progress against.

Estimating

–John Maynard Keynes

“It’s better to be roughly right than precisely wrong.”

Persistance of Time

Exercise: Relative Estimations

Why Relative?

• We are not good in measuring absolute values.

• We are good in comparing things.

• We have the basic math skills (or a calculator).

• High accuracy has a high toll.

• Estimates become commitments

• Time is not persistent.

Story Points

• Name is derived from user stories.

• They reflect the “bigness” of a user story.

• How hard it is ? How risky it is ? How much of it there is ?

• Relative values matters.

Planning Poker

1. Each person gets a deck of cards (Fibonacci).

2. The item to be estimated is read to all.

3. Attendants ask clarifications for the item.

4. Each person selects a card and puts it on the table facing down.

5. When everyone is done, cards are exposed.

6. If the estimations do not match a short discussion is done – Highest & Lowest estimators speak first. -> Goto 4.

7. Handle next item.

12 3 5 8 13 2040

Why Use Planning-Poker?

• Those who do the work estimate it.

• Emphasizes relative estimation

• Estimates are within one order of magnitude.

• Reduces anchoring - Everyone's opinion is heard.

Specification Length

•One page spec•Group A

•7 Pages spec•Group B

173 hours

117 hours

Irrelevant Information

•Group A

•added irrelevant details:•End user desktop apps•Usernames & passwords•Etc.

•Group B

39 hours

20 hours

Extra Requirements

•Requirements 1-4

•Group A

•Requirements 1-5•Group B 4 hours

4 hours

•Requirements 1-5 but told to estimate 1-4 only

•Group C8 hours

Anchoring•Group A

•Customer thinks 500 •customer has no technical knowledge•Don’t let the customer influence you

•Group B555 hours

456 hours

•Same as B customer thinks 50

•Group C99 hours

Why Use Planning-Poker?

• Those who do the work estimate it.

• Emphasizes relative estimation

• Estimates are within one order of magnitude.

• Reduces anchoring - Everyone's opinion is heard.

• Modelled for open discussion – forces thinking.

• It’s quick & fun !

Exercise

Velocity

• How many points can the team complete in one iteration.

• Easy to measure.

• Fixes estimation errors.

• Easily reflects the project status.

• Primary parameter in planning.

Iteration Planning

Description Estimate

As a user I would like to register 3

As a user I would like to login 5

As a buyer I would like to make a bid 3

As a buyer I would like to pay with a

credit card8

As a seller I would like to start an

auction8

This Iteration

Next Iteration

Average Velocity = ~14

Release Planning

Calculating Release Time

http://artparty4u.wix.com/xtremeaverage/apps/blog/wtc-ceo-andrew-messick-on-ironman-swim :מקור

Release Planning

• Given that: – the items for the release are estimated. – The velocity is known (or predicted) – We know the scope or deadline.

• We can estimate one of the two: – how much can we do until the deadline. – How many sprints it will take to complete the

content. • The more data we will have, the more accurate will

be our estimate.

Sprint Planning & Sprint Backlog

Sprint Planning

• The first meeting of the sprint.

• Divided into two parts

• Part I

• Part II

Sprint Planning

• Lasts between 2-8 hours.

• Participants: PO, Team, Scrum Master.

• Product backlog should be in good shape.

• PO should have good understanding of the top backlog items.

Sprint Planning Part I

• Goal: Decide what the team takes to part II in order to commit for sprint content.

• PO Explains the top items from the backlog.

• Team and PO selects the sprint goal.

Sprint Planning Part II

• Goal: Generate the sprint backlog & commit on the sprint’s content.

• The team splits each of the stories into smaller tasks and estimates each task.

• Some design decisions are done.

• Verify that the goal is achievable.

The Sprint Backlog

• An artefact that belongs to the team.

• Assists the team in tracking the sprint’s progress.

• Maximum task length should not exceed 16h for a 4 week sprint.

The Sprint Backlog

• Updated throughout the sprint

• Every team member can add, remove or change the sprint backlog.

• Status of tasks & remaining work is updated daily.

• Sprint content emerges.

The Sprint Backlog - Example

More Task Board Examples

Exercise

Task Board

To do In progress Done

PBI # 1

PBI # 2

Task Board

PBI # 1

PBI # 2

Task Board

PBI # 1

PBI # 2

Task Board

PBI # 1

PBI # 2

Task Board

PBI # 1

PBI # 2

Sprint Planning

• Part I

• Velocity based planning.

• Commitment based planning.

• Part II

• Trust velocity

• Hours & capacity based.

QMultiple parallel programs speed up the development

Multiple programs create big management overhead and risk of overloading the

pipeline, R&D works most efficiently in continuous mode

Burndown Charts

• A simple way of tracking progress.

• Used in different levels:

• Sprint.

• Release.

• Product.

• Shows the amount of work left to reach target.

Release Burndown ChartEf

Sprint

1 2 3 4 5 6 7 8

Sprint Burndown Chart

Daily Scrum

• Daily

• No longer than 15 minutes

• Same place \ same time.

• Stand up.

• All the team must attend.

Daily Scrum

• 3 Questions:

• What have we accomplished since the last daily

• What will we complete until the next daily

• What are my/our impediments.

• Only team members are allowed to speak.

Daily Scrum

• Keep asking

• Is this meeting useful ?

• If not, find out why?

• Is the team reporting to the SM ?

• Does the team share their work ?

• Are impediments removed ?

• Are the reports unclear ?

• Does it take longer than 15 minutes ?

• Etc.

Exercise

Sprint Review

• Held At the end of each sprint.

• This is —-NOT—- a Sprint Demo

• During this meeting the team presents to the management\customers\users\product owner, what work has been DONE and what was not.

• The only form of “automated” presentations allowed is working software, Slideware is banned.

• The things that were not accomplished will be returned to the product backlog.

Retrospective

Sprint Retrospective

• Key feature of inspect & adapt

• Periodically take a look at what is and is not working

• Typically 1-2 hours

• Done after every sprint (for sprint retrospective)

• Who participates ?

• Scrum Master - facilitates

• Product owner

• Team – all of the team.

• Possibly customers and others

• The goal of the meeting is to generate action items (Experiments) to execute next sprint

• Things to stop doing.

• Things to keep doing.

• Things to start doing.

Retrospective Model Example

• Opening (2-5 minutes)

• Data collection (15-25 minutes)

• Generate insights (15-25 minutes)

• Create experiments (15-25 minutes)

• Closing (2-5 minutes)

Opening

• 1 word

• SAD \ MAD \ GLAD

• Score the sprint.

Data collection

To keep \ To change

• List the things in two columns.

• Prioritize each column.

• Take top 3 from each column.

• Prioritize again.

Timeline

• Draw a chart on the board.

• Have each team member write meaningful events.

• Put sticky notes on the board at the relevant time.

• Group items based on time\topic\else.

• 1 is also a group.

• Prioritize.

Spider web

• Draw a spider web on the board.

• Write attributes that are important to you on each edge.

• Have each team member rate each attribute.

• Discuss the most painful one.

• Repeat until the time is over.

Generate insights

• Silent grouping.

• 5 why’s.

• Spin dating.

Create Experiments

• Not many experiments.

• Experiment should be:

• S.M.A.R.T Specific, Measurable, Attainable, Relevant, Timely

Closing

• Action items owners.

• And:

• Rate the retrospective.

• SAD \ MAD \ GLAD.

QProduct development process can be defined as a predictable and

repeatable process

Product development is an evolving and adaptive process

Scrum Simulation

Exercise

Scaling Scrum

• Do it only if you must!

• Scrum can be implemented without scaling for ~100 people.

• Sometimes it is better to have less people working on a project.

• Focus on synchronization & communication.

• CI at the top level

• Scrum of scrums.

• Multiple team sprint planning.

• COP – communities of practice.

• The right organizational structure

Scaling Sprint Planning

Planning part I Product owner

Representative of each team

backlog

Planning part II Team 1

Select

backlo

g items

Select items

Select backlog items

sprintbacklog

– Every team sends one representative (Not the Scrum master!!!)

Daily Scrum 10:00 am Team 1

Daily Scrum 11:00

Scrum of scrums Team

representatives

Extra question: Do we intend to

create a problem

Organization Structure

The Traditional Way - Component Teams

Component A

Component B

Component C

Component D

The Traditional Way - BottleneckComponent A

Component B

Component C

Component D

Release feature list:

•Feature 1 – A(20%) B(30%) C(50%)

•Feature 2 – A(40%) B(20%) D(40%)

•Feature 3 – B(80%) C(20%)

•Feature 4 – A(50%) C(50%)

•Feature 5 – A(20%) C(70%) D(10%)

Total Effort needed: A – 210 B – 130 C – 190 D – 50

The Traditional Solutions

• Move people from team to team to match requirements A(5) , B(3), C(5), D(2).

• Decreases job satisfaction, hurts performance.

• What will happen next release ?

• Leave team formation as is:

• Some teams will be “unemployed” – What will they do ?

• Need to “invent” work for them.

• Other teams will have too much pressure.

• Change the scope of the release to equalize efforts:

• Still bottlenecks exists on feature level.

• The problem will be worst next release.

Feature Teams

Sources of Requirements

Component A

Component B

Component C

Component D

Security related

Features

User admin related features

Item CRUD related features

Reporting related features

Feature Teams

• All teams have cross component ability.

• This might take some time.

• All team produce E2E functionality.

• Immediately reduces bottlenecks, reduces waste.

• Long term, eliminate this bottleneck.

• Increases flexibility – allows development by business value.

• Requires increased communication between teams (this is a good thing!)

• Increases business understanding inside teams.

• Requires commitment and effort to implement.

Component A

Component B

Component C

Component D

Release feature list:

•Feature 1 – A(20%) B(30%) C(50%)

•Feature 2 – A(40%) B(20%) D(40%)

•Feature 3 – B(80%) C(20%)

•Feature 4 – A(50%) C(50%)

•Feature 5 – A(20%) C(70%) D(10%)

Feature 1

Feature 2

Feature 3

Feature 4

Total Effort needed: A – 210 B – 130 C – 190 D – 50

Scaling the PO Role

• Easy when feature teams exists.

• Instead of a PO have a PO team.

• Each team member is an APO – Area product owner.

• Area product owner focuses on one or more requirement areas.

• Team decides together how the general prioritization of the back log is.

• Each APO has the responsibility to support, follow and prioritize within his area\s.

• APOs report back to the team for adaptations.

• Usually an APO deals with the same teams for a long period of time.

Appendix

practical scrum course day 2

Leadership & Management

practical russian course

course objectives the scrum framework certified ... ·...

practical application of scrum final

20121211 certified-scrum-master-course

practical scrum course day 1

practical piping course

practical example of scrum and kanban use in the same...

crash course scrum - handout

online certiﬁed scrum professional scrum master...scrum...

let’s try scrum for in a university course

certiﬁed scrum professional scrum master...scrum master®...

national 4 practical electronics course support · pdf...

practical skills evaluator training course · practical...

scrum crash course - arjan franzen & hugo messer

experience: practical methods for scaling scrum

agile scrum foundation course

practical alchemy course

practical scrum - day 1

tytuł oryginału: essential scrum: a practical guide to the...

online live & e-learning scrum master certification ... ·...