Scrum part 2

Kari Systä, 16.02.2015

16.02.2015 TIE-21100/21106; KSY 1

About our schedule

16.02.2015 TIE-21100/21106; KSY 2

Lecture Weekly e. Project

Scrum (part 1) Processing

Requirements management

Agilefant Sprint 1 starts

Version and configuration management

Git

Scrum (part 2) Patterns

Project planning (part 2) – Effort esitimation

Effort estimation

Sprint 2 starts

About the project • If you have members who still have not replied,

inform marko.leppanen@tut.fi • Reservation for 1st sprint review meetings will

open today and done by end of this week – You will receive a message

• Think about your end-presentation – If you do not use processing, check that you can use

emulator or browser

• If you want to gain bonus points from using Git provide access to your assistant during 1st print

• Project plans to returned in Canvas

16.02.2015 TIE-21100/21106; KSY 3

Today’s agenda

• A short recap of version and configuration management

• Recap of the basics of Scrum

• Dive deeper to Scrum

– Requirements management and Scrum

– Roles in Scrum

16.02.2015 TIE-21100/21106; KSY 4

What is configuration management?

• Change management: managed way to decide which change ideas to implement and when.

• Version management: keep track of multiple versions of components and ensure that changes by different developers do not disturb each other.

• System building: collect and assemble correct versions of required components and then compile.

• Release management: prepare for external releases and keep track of external releases.

16.02.2015 TIE-21100/21106; KSY 5

Figure 25.1 in Sommerville

16.02.2015 TIE-21100/21106; KSY 6

Component versions

System versions

System releases

System building

Change management

Version management

Release management

Change proposals

From http://git-scm.com/book/en/v2

16.02.2015 TIE-21100/21106; KSY 7

From same book

16.02.2015 TIE-21100/21106; KSY 8

Scrum

• Recap from the lecture of 26.01.

• About backlog and ”requirements managament”

• Roles of Product Owner and Scrum Master

• Main material: http://www.scrumguides.org/

16.02.2015 TIE-21100/21106; KSY 9

Mountain Goat Software,

LLC

Scrum

Cancel

Gift wrap

Return

Sprint

2-4 weeks

Return

Sprint goal

Sprint

backlog Potentially shippable

product increment

Product

backlog

Coupons Gift wrap

Coupons

Cancel

24 hours

Mountain Goat Software,

LLC

Sprints

• Scrum projects make progress in a series

of “sprints”

• Analogous to Extreme Programming iterations

• Typical duration is 2–4 weeks or a calendar

month at most

• A constant duration leads to a better

rhythm

• Product is designed, coded, and tested

during the sprint

Requirement mgmt hierarchy in Agilefant

02.02.2014 TIE-22100/22106 12

Product

Project Project Project Project

Iteration Iteration Iteration Iteration

Story Story Story Story

Task Task

About Product Backlog (From Scrum Guide)

• The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.

• The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

• A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements.

• The Product Backlog evolves as the product and the environment in which it will be used evolves.

• The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.

• As long as a product exists, its Product Backlog also exists.

16.02.2015 TIE-21100/21106; KSY 13

Product Backlog has a central role

16.02.2015 TIE-21100/21106; KSY 14

Product backlog

Customers

Developer team

Market

Competition

Team Team Team

Product Backlog refinement

• The act of adding detail, estimates, and order to items in the Product Backlog.

• Ongoing process in which the PO and the Development Team collaborate on the details of Product Backlog items.

• During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done.

• Refinement usually consumes no more than 10% of the capacity of the Development Team.

• However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

• Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones.

16.02.2015 TIE-21100/21106; KSY 15

Scrum and requirements process

• ”The earliest development of it only lays out the initially known and best-understood requirements.”

• Is that enough to allocate resources and start a project?

• Very seldom!

• Luckily!

16.02.2015 TIE-21100/21106; KSY 16

There is no single truth. Depends on the case (and opinions)

• Before the projects starts there needs to be understanding of the user requirements.

– Either explicitly or implicitly

• ”We’ll do what you like” is seldom enough to make a deal.

16.02.2015 TIE-21100/21106; KSY 17

Some hints for writing user stories:

think about different users (even personas)

• Like in users case diagrams in UML

16.02.2015 TIE-21100/21106; KSY 18 16.9.2013

Product

Owner

Add to

product

Backlo

g

Update

effort

estimates

See

Burndow

n

chart

Agilefant

JOTU2013/K.Systä

Scrum

master

Team

member

Collaborate

16.02.2015 TIE-21100/21106; KSY 19

Product

Owner

Product backlog

Customer

Team

KISS (Keep It Simple, Stupid)

•As <persona> I want <what> so that <why/value>

16.02.2015 TIE-21100/21106; KSY 20

Mountain Goat Software,

LLC

Product owner

• Define the features of the product

• Decide on release date and content

• Be responsible for the profitability of the

product (ROI)

• Prioritize features according to market

value

• Adjust features and priority every iteration,

as needed

• Accept or reject work results

Product Owner (source: Scrum Guide)

• The Product Owner is responsible for maximizing the value of the product and the work of the Development Team.

• The sole person responsible for managing the Product Backlog

• Clearly expressing Product Backlog items;

• Ordering the items in the Product Backlog to best achieve goals and missions;

• Optimizing the value of the work the Development Team performs;

• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,

• Ensuring the Development Team understands items in the Product Backlog to the level needed.

16.02.2015 TIE-21100/21106; KSY 22

Product Owner • The Product Owner may do the above work, or have

the Development Team do it. However, the Product Owner remains accountable.

• The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

• For the Product Owner to succeed, the entire organization must respect his or her decisions.

• The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.

16.02.2015 TIE-21100/21106; KSY 23

Mountain Goat Software,

LLC

The ScrumMaster

• Represents management to the project

• Responsible for enacting Scrum values and

practices

• Removes impediments

• Ensure that the team is fully functional and

productive

• Enable close cooperation across all roles and

functions

• Shield the team from external interferences

Scrum Master

• The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.

• The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.

• The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

16.02.2015 TIE-21100/21106; KSY 25

Scrum Team

• Team are self-organizing. No one (not even the Scrum Master) tells how to turn Product Backlog into Increments;

• Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;

• Scrum recognizes no titles for Development Team members other than Developer;

• No sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis;

• Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

• 3-9 (5-9) members – Enough skills – Not too much coordination

16.02.2015 TIE-21100/21106; KSY 26

Sprint planning

• Collaborative work of the entire Scrum Team and last maximum 8 hours.

• Topic One: What can be done this Sprint? – ” The Product Owner discusses the objective that the

Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.”

– After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal.

16.02.2015 TIE-21100/21106; KSY 27

Sprint Planning

Topic Two: How will the chosen work get done? • ” Having set the Sprint Goal and selected the Product Backlog items

for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. ”

• “The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment.”

• ” The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. ”

• ” By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment. ”

16.02.2015 TIE-21100/21106; KSY 28

Managing the sprint backlog • Any team member can add, delete or change the

sprint backlog

• Work for the sprint emerges

• If work is unclear, define a sprint backlog item with a larger amount of time and break it down later

• Update work remaining as more becomes known

16.02.2015 TIE-21100/21106; KSY 29

02.02.2014 TIE-22100/22106 30

Product

Project Project Project Project

Iteration Iteration Iteration Iteration

Story Story Story Story

Task Task Task

My earlier slide looked exact but was not…

Effort estimation

• The effort required by each task need to be estimated and documented in Sprint Backlog

• Topic of a separate lecture

16.02.2015 TIE-21100/21106; KSY 31

Sprint Planning

• Items to be considered, too:

– Is some architecture refactoring needed?

– Testing and other quality matters

• Sprint Goal

– Gives the overall target – what is really important.

– Reminds about the focus

– Gives a guideline if compromises are needed

16.02.2015 TIE-21100/21106; KSY 32

Managing the sprint backlog • Any team member can add, delete or change the

sprint backlog

• Work for the sprint emerges

• If work is unclear, define a sprint backlog item with a larger amount of time and break it down later

• Update work remaining as more becomes known

16.02.2015 TIE-21100/21106; KSY 33

Managing the sprint backlog (when done by the book)

• Individuals sign up for work of their own choosing

– Work is never assigned by a “manager”

• Estimated work remaining is updated daily

• This maximizes the transparency

16.02.2015 TIE-21100/21106; KSY 34

A sprint burndown chart H

ou

rs

16.02.2015 TIE-21100/21106; KSY 35

Example

Tasks

Code the user interface

Code the middle tier

Test the middle tier

Write online help

Write the foo class

Mon

8

16

8

12

8

Tues

4

12

16

8

Wed Thur

4

11

8

4

Fri

8

8

Add error logging

8

10

16

8

8

16.02.2015 TIE-21100/21106; KSY 36

Ho

urs

40

30

20

10

0 Mon Tue Wed Thu Fri

Tasks

Code the user interface

Code the middle tier

Test the middle tier

Write online help

Mon

8

16

8

12

Tues Wed Thur Fri

44

4

12

16

7

11

8

10

16 8

50

16.02.2015 TIE-21100/21106; KSY 37

32 34 18 8

What to include in Sprint backlog

• Meeting?

• Bureaucracy?

• There is no exact guideline, but all tasks

– Should have definition of done

– Add customer value

16.02.2015 TIE-21100/21106; KSY 38

About scalability of Scrum

• Typical individual team is 7 ± 2 people

– Scalability comes from teams of teams

• Factors in scaling

– Type of application

– Team size

– Team dispersion

– Project duration

• Scrum has been used on multiple 500+ person projects

16.02.2015 TIE-21100/21106; KSY 39

Scaling through the Scrum of scrums

16.02.2015 TIE-21100/21106; KSY 40

Scrum of scrums of scrums

16.02.2015 TIE-21100/21106; KSY 41

”Theory of Scrum”

• Transparency

– A common language referring to the process must be shared by all participants; and,

– hose performing the work and those accepting the work product must share a common definition of “Done”.

• Inspection

– Scrum users must frequently (but not too frequently) inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.

• Adaptation

16.02.2015 TIE-21100/21106; KSY 42

27.1.2014 43

Timeboxing • http://guide.agilealliance.org/guide/timebox.html:

– A timebox is a previously agreed period of time during which a person or a team works steadily towards completion of some goal. Rather than allow work to continue until the goal is reached, and evaluating the time taken, the timebox approach consists of stopping work when the time limit is reached and evaluating what was accomplished

• Ways to manage risks • Fast response • Makes requirement management more rigid

TB1 TB2 TB3

TIE-21100/21106/K.Systä

Where to go next

• www.mountaingoatsoftware.com/scrum

• www.scrumalliance.org

• www.controlchaos.com

• scrumdevelopment@yahoogroups.com

16.02.2015 TIE-21100/21106; KSY 44

A Scrum reading list • Agile and Iterative Development: A Manager’s Guide by Craig

Larman

• Agile Estimating and Planning by Mike Cohn

• Agile Project Management with Scrum by Ken Schwaber

• Agile Retrospectives by Esther Derby and Diana Larsen

16.02.2015 TIE-21100/21106; KSY 45

A Scrum reading list • Agile Software Development Ecosystems by Jim Highsmith

• Agile Software Development with Scrum by Ken Schwaber and Mike Beedle

• Scrum and The Enterprise by Ken Schwaber

• Succeeding with Agile by Mike Cohn

• User Stories Applied for Agile Software Development by Mike Cohn

http://www.scrumguides.org/

(in many languages)

16.02.2015 TIE-21100/21106; KSY 46

Final note

• Each organization has it own variation but it is good to learn the ideas of ”by-the-book Scrum” first.

16.02.2015 TIE-21100/21106; KSY 47