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: [email protected]

blog: http://fostnope.com/

mailto:[email protected]

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


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

1

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-

front

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”

Daily

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


34.4


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

3 5 3

Next Iteration

8 8

Average Velocity = ~14


Release Planning


Calculating Release Time

S

T

V

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

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


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


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

fort

rem

aini

ng

0

25

50

75

100

Sprint

1 2 3 4 5 6 7 8


Sprint Burndown Chart


Sprint Burndown Chart


Daily Scrum


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


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


Exercise


Exercise


Exercise


Exercise


Exercise


Exercise


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

sprintbacklog

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


Recommended Links

• Scrum alliance – www.scrumalliance.org

• Scrum development group on yahoo – groups.yahoo.com\group\scrumdevelopment

• Agile alliance – www.agilealliance.org

• infoQ – www.infoq.com

• Agile Practitioners IL Discussion Group http://www.linkedin.com/groups/Agile-Practitioners-IL-81807

• My blog – http://fostnope.com

• Practical Agile website - http://www.practical-agile.com/

http://www.scrumalliance.org/

http://www.groups.yahoo.com/group/scrumdevelopment

http://www.agilealliance.org/

http://www.infoq.com/

http://www.linkedin.com/groups/Agile-Practitioners-IL-81807

http://fostnope.com

http://www.practical-agile.com/


Recommended Books

• Ken Schwaber & Mike beedle – Agile software development with Scrum

• Ken Schwaber – Agile project management with Scrum.

• Ken Schwaber – Enterprise Scrum.

• Bass Vodde & Craig larman - Scaling Lean & Agile Development (2 books)


Other Recommended Books

• Tom DeMarco & Timothy lister – Peopleware.

• Frederick P. Brooks - The Mythical Man-Month

• Craig Larman – Agile & Iterative software development.

• Mary Lynn Manns and Linda Rising - Fearless change

• Diana Larsen & Esther Derbey – Agile retrospectives

• Mike Cohn – Agile estimation and planning.

• Mike Cohn – User stories applied.

• Test Driven (java) – Lasse koskalle

• Clean code – Robert C. Martin.

• And many more…


References and Additional Sources

• 1970 - Managing the development of large software systems (aka Waterfall Model, Winston Royce) http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf

• 1986 – The new, new software development game (Takeuchi & Nonaka) http://files.meetup.com/1671339/The%20New%20New%20Product%20Development%20Game.pdf

• Liker\Hoseus 2008 – The Toyota Way http://www.amazon.com/The-Toyota-Way-Management-Manufacturer/dp/0071392319

• 2001 - Agile Manifesto http://agilemanifesto.org

• 1991-2013 - The Scrum Guide (Schwabber, Sutherland) https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf

http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf

http://files.meetup.com/1671339/The%20New%20New%20Product%20Development%20Game.pdf

http://www.amazon.com/The-Toyota-Way-Management-Manufacturer/dp/0071392319

http://agilemanifesto.org

https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf



• 1971 - The Psychology of Computer Programming (G. Weinberg) http://www.amazon.com/The-Psychology-Computer-Programming-Anniversary/dp/0932633420

• 1987 - Peopleware, Productive Projects and Teams (T. De-Marco) http://www.amazon.com/Peopleware-Productive-Projects-Teams-3rd/dp/0321934113

• 2003 - Lean Software Development: An Agile Toolkit (M&T Poppendieck) http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783

• 1999 - Extreme Programming Explained (K. Beck & C. Andres) http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658

http://www.amazon.com/The-Psychology-Computer-Programming-Anniversary/dp/0932633420

http://www.amazon.com/Peopleware-Productive-Projects-Teams-3rd/dp/0321934113

http://www.amazon.com/Lean-Software-Development-Agile-Toolkit/dp/0321150783

http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658



• 2004 - Working Effectively with Legacy Code (M. Feathers) http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

• 1975 - The Mythical Man-Month (F. P. Brooks) http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

• This is Water video https://www.youtube.com/watch?v=DKYJVV7HuZw

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959

https://www.youtube.com/watch?v=DKYJVV7HuZw


End of day 2

Practical Scrum course day 2

Leadership & Management