© Timothy Korson Page 1 Scrum by Dr. Korson For CPTR 209 Software Engineering Version 10.1103.

31
© Timothy Korson Page 1 Scrum by Dr. Korson For CPTR 209 Software Engineering Version 10.1103

Transcript of © Timothy Korson Page 1 Scrum by Dr. Korson For CPTR 209 Software Engineering Version 10.1103.

© Timothy Korson Page 1

Scrum by

Dr. Korson

For

CPTR 209 Software Engineering

Version 10.1103

© Timothy Korson Page 2

How does a mature, disciplined, test driven, agile process work?

I will use Scrum as an example

© Timothy Korson Page 3

Scrum

• Scrum in the sport of rugby, is a way of restarting the game, either after an accidental infringement or (in rugby league only) when the ball has gone out of play.

© Timothy Korson Page 4

Three Scrum Roles

• the ScrumMaster, who maintains the processes

• the Product Owner, who represents the stakeholders and the business

• the Team, a cross-functional group of who do the actual analysis, design, implementation, testing, etc.

© Timothy Korson Page 5

Where is the Project Manager?

© Timothy Korson Page 6

Protecting the Team

CORPORATEZONE

AGILE ZONE

BUFFER

ZONE

Regulatory agencies

Senior management

Process groups

System integrationTeam

Pro

j ec t

ma

na

ge r

© Timothy Korson Page 7

Chicken and Pig

Scrum requires a commitment.

© Timothy Korson Page 8

Pig Roles

The Pigs are the ones committed to the project in the Scrum process—they are the ones with “their bacon on the line” and performing the actual work of the project.

• ScrumMaster o Scrum is facilitated by a ScrumMaster, also written as Scrum

Master, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal/deliverables. The ScrumMaster is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences.

o Cross-Functional Team o The team has the responsibility to deliver the product.

o Product Owner o The Product Owner ensures that the Scrum Team works on the

“right things” from a business perspective. The Product Owner keeps the product backlog ordered and groomed.

© Timothy Korson Page 9

Chicken Roles

Chickens are not involved in the day to day Scrum process, but must be taken into account. They are people for whom the software is being built.

• Stakeholders (customers, vendors)– They are only directly involved in the process

during the sprint reviews. • Managers • Executives• Marketing personnel

© Timothy Korson Page 10

Super Chickens

– Senior managers or other persons important to the project are sometimes called super chickens..

– Chickens (even super chickens) only access to the team is to the Product Owner

© Timothy Korson Page 11

Kicking off a Scrum Project

• Business justification – ROI calculations, etc.• Project scope, duration, and budget is determined• Product owner

– elaborates the project scope into a list of desired features (“stories”) called the product backlog

– gets consensus on relative business value of each feature in the product backlog from the stakeholders

– gets from the technical team a ballpark estimate on the relative effort of developing each feature

– sequentially orders the product backlog according to long term ROI

– gathers additional requirement details for the top 20% of the features in the product backlog.

© Timothy Korson Page 12

Product Backlog

• The product backlog contains broad descriptions of all required features, wish-list items, etc. rank ordered so as to maximize long term ROI.

• The backlog can be reordered, added to, or deleted from, at any time by the product owner.

• The product backlog is the property of the Product Owner. Business value is known by the Product Owner. ROI can only be calculated after development effort is estimated by the Team.

© Timothy Korson Page 13

Sprint Planning Meeting

– (1st part) Product Owner + Team: Work to clarify

Product Backlog items and determine which ones will go into the Sprint Backlog

– (2nd part) Team (PO must be available): hashing out a plan for the Sprint, resulting in the Sprint Item Backlog

© Timothy Korson Page 14

Sprint Planning Meeting

• It is the responsibility of the product owner to articulate the business goals and vision for the current sprint

• It is the responsibility of the team to brainstorm with the product owner to envision product possibilities for the current sprint

• Only the technical team knows– Technical possibilities

• New technology• Libraries of existing

capability

– Implementation resources needed

– Technical risk

© Timothy Korson Page 15

Sprint Backlog (WBS)

• Features are broken down into tasks; – tasks are normally estimated between four and

eight hours of work. – Tasks on the sprint backlog are never assigned;

rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills.

• The sprint backlog is the property of the Team. Estimations are set by the Team.

© Timothy Korson Page 16

Task Board

© Timothy Korson Page 17

Burn Down Chart

© Timothy Korson Page 18

Another Burn Down Chart

© Timothy Korson Page 19

Clarity in the Product Backlog• Feature 1• Feature 2• Feature 3• Feature 4• Feature 5• Feature 6• Feature 7• Feature 8• Feature 9• Feature 10• Feature 11• Feature 12• Feature 13• Feature 14• Feature 15• Feature 16• Feature 17• Feature 18• Feature 19• Feature 20

RELEASE 0.1

RELEASE 0.2

RELEASE 0.3

RELEASE 1.0

Based on current backlog ranking and project velocity

This is a live document

© Timothy Korson Page 20

Daily Scrum

• The meeting starts precisely on time.• Only “pigs” may speak• The meeting is timeboxed to 15 minutes• During the meeting, each team member answers three

questions:

1. What have you done since yesterday that contributes to

reducing the sprint backlog?

2. What are you planning to do today that will reduce the sprint

backlog?

3. Are there any obstacles hindering you from accomplishing

your goal?

© Timothy Korson Page 21

Purpose of the Daily Scrum

© Timothy Korson Page 22

Sprint Review Meeting

• Review the work that was completed and not completed

• Present the completed work to the stakeholders• Incomplete work cannot be demonstrated• Sprint Backlog is often revised based on ideas

generated during the Sprint review

WRAP AND SHIP

© Timothy Korson Page 23

Sprint Retrospective

• All team members reflect on the past sprint• Make continuous process improvements• Two main questions are asked in the sprint

retrospective: – What went well during the sprint? – What could be improved in the next sprint?

• Three hour time limit

© Timothy Korson Page 24

Scrum of Scrums

• Scrum of scrums allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.

• A designated person from each team attends and answers the following four questions:

1. What has your team done since we last met?

2. What will your team do before we meet again?

3. Is anything slowing your team down or getting in their way?

4. Are you about to put something in another team’s way?

© Timothy Korson Page 25

Scrum Integration Team

Product Integration

Team

Product Team 1

Product Team 2

Product team 3

Product Team 4

© Timothy Korson Page 26

Release Backlog

• Even though all sprint results are potentially releasable, it may not make business sense to do so.

• The sprint schedule is overlaid with a release schedule.

• The release backlog is the property of the Product Owner. The product owner monitors the release burndown chart, and adjuststhe release backlog to reflectreality.

© Timothy Korson Page 27

Best Case – Worse Case

• Worst 3 sprints – 16 story points• Best 3 sprints – 28 story points• Average Velocity – 22 story points

Product Backlog has 163 story points• Worst case – 163/16 = 11 sprints• Best case – 163/28 = 6 sprints• Expected case – 163/22 = 8 sprints

© Timothy Korson Page 28

Welcomes Changing Requirements

sprint

new requirement!

© Timothy Korson Page 29

Scrum-ban

A software production model based on Scrum and Kanban

The major differences between Scrum and Kanban are derived from the fact that in Scrum work is divided into sprints that last a certain amount of time, whereas in Kanban the workflow is continuous

© Timothy Korson Page 30

Scrum

Pro

du

ct

Backlo

g

Release Backlog

Continuous Flow of Business Value

© Timothy Korson Page 31

Scrum Summary

• 3 roles– Scrum master– Product Owner– Team

• 3 artifacts– Product Backlog– Sprint Backlog– Burndown chart

• 3 Ceremonies– Sprint Planning– Daily Scrum– Sprint review and retrospective