scrum training for team

47
SCRUM Introduction Johnny Zhang Honeywell Security 1

Upload: johnyzhang

Post on 26-Jan-2015

85 views

Category:

Technology


1 download

DESCRIPTION

 

TRANSCRIPT

Page 1: Scrum training for team

Honeywell Security 1

SCRUM Introduction

Johnny Zhang

Page 2: Scrum training for team

Honeywell Security 2

Agenda

WHAT & WHY SCRUM

SCRUM Activities

NS3 VE Milestone 2

Page 3: Scrum training for team

Honeywell Security 3

What is SCRUM

Scrum project management is a software agile development process. Scrum models allow projects to progress via a series of iterations called agile sprints

Page 4: Scrum training for team

Honeywell Security 4

Agile Manifesto

Page 5: Scrum training for team

Honeywell Security 5

SCRUM Values Focus. 

Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner

Courage.  Because we are not alone, we feel supported and have more resources at our

disposal. This gives us the courage to undertake greater challenges. Openness. 

As we work together, we practice expressing how we're doing, and what's in our way. We learn that it is good to express concerns, so that they can be addressed.

Commitment.  Because we have great control over our own destiny, we become more

committed to success. Respect. 

As we work together, sharing successes and failures, we come to respect each other, and to help each other become worthy of respect.

Page 6: Scrum training for team

Honeywell Security 6

Waterfall issues

Give me all requirements, otherwise it will cost you!

Page 7: Scrum training for team

Honeywell Security 7

Waterfall issues

Emergence! Impossible to know all requirements in

advance ”Thinking harder” and ”thinking longer”

can uncover some requirements, but

EVERY PROJECT HAS SOME EMERGENT REQUIREMENTS

Emergent requirements are those that we cannot identify in advance

Page 8: Scrum training for team

Honeywell Security 8

Real Software World

Page 9: Scrum training for team

Honeywell Security 9

Game

6 people to Join

Page 10: Scrum training for team

Honeywell Security 10

Why SCRUM

So what do we do We talk more, write less

But write if you have to Show software to users Acknowledge that requirements emerge

And all that this implies Progressively refine our understanding of the

product Express this progressive refinement in the product

backlog

Page 11: Scrum training for team

Honeywell Security 11

Why SCRUM : 3 pillars Transparency

ALL relative aspects of the process must be visible to those responsible for the outcome.  This requires a common standard and nomenclature between the Scrum Team.

Inspection The Scrum process promotes frequent Inspection of

the Artifacts and progress to identify and correct undesirable variances.  Inspection occurs during the Sprint Planning Meeting, Daily Scrum, Sprint Review and Sprint Retrospective (collectively referred to as the Scrum Events).

Adaption After Inspection, adjustments should be made to the processes

and Artifacts to minimize further deviation.

Page 12: Scrum training for team

Honeywell Security 12

How :SRUM Roles

Page 13: Scrum training for team

Honeywell Security 13

SCRUM Team

Page 14: Scrum training for team

Honeywell Security 14

Emergency Procedures

Be creative

Get help

Decrease scope

Abort Sprint

Page 15: Scrum training for team

Honeywell Security 15

Done!

Page 16: Scrum training for team

Honeywell Security 16

SCRUM Activities

Page 17: Scrum training for team

Honeywell Security 17

Product backlog

List of things that needs do be done to achieve desired state

Emergent, ordered, estimated More detail on higher priority backlog One list for multiple teams Product Owner responsible for ordering Anyone can contribute Maintained and posted visibly Comes from Business Plan, Brain Storming,

Vision Statement, etc

Page 18: Scrum training for team

Honeywell Security 18

Product backlog

Page 19: Scrum training for team

Honeywell Security 19

Product backlog Visibility

Page 20: Scrum training for team

Honeywell Security 20

Product backlog visibility

Page 21: Scrum training for team

Honeywell Security 21

User Story

A User Story is a story, told by the user, specifying how the system is supposed to work, written on a card, and of a complexity permitting ,estimation of how long it will take to implement.

The User Story promises as much subsequent conversation as necessary to fill in the details of what is wanted. The cards themselves are used as tokens in the planning process after assessment of business value and [possibly] risk. The customer prioritizes the stories and schedules them for implementation. – Ron Jeffries

Page 22: Scrum training for team

Honeywell Security 22

User Story template

As a/an <type of user>,I want <some goal>so that <some reason>

The “so that” line is generally considered optional, but used as a default

Page 23: Scrum training for team

Honeywell Security 23

User Story Examples

As a user I want to be able to set the alarm on my cell phone so I can get up in the morning.

As a snoozer I want to be able to activate ‘snooze’ when the alarm goes off, so I can sleep 10 minutes more.

As a user I want to set the alarm so I can get up at the same time every morning.

Page 24: Scrum training for team

Honeywell Security 24

User Story Exercise

Write user story for NS3 VE

Reference : NS3VE Schedule

Page 25: Scrum training for team

Honeywell Security 25

User story checklist Independent. User Stories should not overlap in terms of the value

they deliver.

Negotiable. It should be possible to debate and change User Stories, and to trade them in and out of scope.

Valuable. Every User Story must deliver stakeholder benefit. Estimable. It should be possible to anticipate how much effort a User

Story will require for implementation.

Small. It is better to work on multiple small pieces of work than a larger one, since progress is more easily ascertained and at least some value can potentially be delivered earlier.

Testable. It should be possible to confirm the successful completion of a User Story by objective means.

Page 26: Scrum training for team

Honeywell Security 26

User story Exercise again

NS3 VE user story update? Considering we understand NS3 well, we need

more details ones

Page 27: Scrum training for team

Honeywell Security 27

User story points

Poker Planning Team finds an easy PBI (not the easiest) and

agree it is a 2 Team agrees on a PBI that takes 4 times as long

as the 2 and assign it to 8.

Page 28: Scrum training for team

Honeywell Security 28

User story points

How to finish estimating a PBI Play 3 times and assign estimate as the

average of all numbers Continue until consensus Continue until all estimates are within 2

numbers. The higher value (if at least two) is the estimate

Continue until all are within 3 numbers. Estimate is the middle value

Page 29: Scrum training for team

Honeywell Security 29

Sprint Planning

1 hour per part per week 1st – for team to select Product Backlog and

sets goal with Product Owner 2nd - for team to define Sprint Backlog to

build functionality Anyone can attend, but primary

conversation and work is between team and Product Owner

Page 30: Scrum training for team

Honeywell Security 30

Sprint Planning

Page 31: Scrum training for team

Honeywell Security 31

Sprint backlog Tasks to turn product backlog into working product

functionality Tasks are estimated in hours Tasks with more than 1 day of work are broken down Team members sign up for tasks, they aren’t assigned (be

patient, just wait!) Estimated work remaining is updated daily Any team member can add, delete or change the Sprint Backlog

(theirs or new) Update work remaining as more is known, as items are worked

Page 32: Scrum training for team

Honeywell Security 32

Sprint backlog

Page 33: Scrum training for team

Honeywell Security 33

SCRUM Board Do one PBI at a time!!

Page 34: Scrum training for team

Honeywell Security 34

Burndown Chart

Page 35: Scrum training for team

Honeywell Security 35

Sprint Abnormal Termination Sprints can be cancelled before the allotted

Sprint is over; Product Owner is only one that can cancel a

Sprint; Sprints may be cancelled because of changes in

competition, business, or technology feasibility. More normally, scope of Sprint is adjusted.

If a Sprint is abnormally terminated, the next step is to conduct a new Sprint planning meeting, where the reason for the termination is reviewed.

Page 36: Scrum training for team

Honeywell Security 36

Sprint Abnormal Termin Ceremony

Page 37: Scrum training for team

Honeywell Security 37

Daily SCRUM

Daily 15 minute meeting Same place and time every day Meeting room Three questions

What have you done since last meeting? What will you do before next meeting? What is in your way?

Page 38: Scrum training for team

Honeywell Security 38

Daily SCRUM

”If I had known how the questions from the Daily Scrum are used today I would have framed them differently, but it is to late to change it now” Jeff Sutherland – April 2012

• Yesterday I helped the team by………

• Today I will help the team by…….. • I am blocked from helping the team

by……..

Page 39: Scrum training for team

Honeywell Security 39

Daily SCRUM

Team owns the meeting and decide who can talk It is a conversation, not a discussion. Keep meetings crisp, focused on answering the three questions; Setup meetings following the Daily Scrum

as needed Time Boxed to 15 minutes

Page 40: Scrum training for team

Honeywell Security 40

Social contract Hang it on the wall

If change – bring to retrospective Examples:

Pair programming Test early rules Time of daily scrum Penalty being late Phone usage Quiet periods

Page 41: Scrum training for team

Honeywell Security 41

SCRUM Environment

Page 42: Scrum training for team

Honeywell Security 42

Sprint Review

Not a Sales meeting No PowerPoint presentation Maximum 1 hour preparation Done on equipment where software was

developed and tested Time boxed to 4 hours Reviewed by Team, Product Owner and

other stakeholders. This a collaborative working session, not a

demonstration.

Page 43: Scrum training for team

Honeywell Security 43

Sprint Review rules 1

Sprint Review includes at least following 1 The Product Owner identifies what has

been done and what hasn’t been done. The Team discusses what went well

during the Sprint and what problems it ran into, and how it solved these problems.

The Team then demonstrates the work that is done and answers questions.

Page 44: Scrum training for team

Honeywell Security 44

Sprint Review rules 2

Sprint Review includes at least following 2 The Product Owner then discusses the Product

Backlog as it stands. He or she projects likely completion dates with various velocity assumptions.

The entire group then collaborates about what it has seen and what this means regarding what to do next.

The Sprint Review provides valuable input to subsequent Sprint Planning meeting.

Page 45: Scrum training for team

Honeywell Security 45

Sprint Retrospective

What went well What could have been better (Find

root cause - 5 * why) Things to try Issues to escalate (to Management)

Page 46: Scrum training for team

Honeywell Security 46

Consideration

How to do NS3VE project in SCRUM

Concerns

Page 47: Scrum training for team

Honeywell Security 47

Summery

What we learned today What , why , how SCRUM SCRUM activities

product backlog Sprint Plan Daily meeting Sprint Review Sprint Retrospective

NS3VE in SCRUM