Book 1_Scrum Agile

8/2/2019 Book 1_Scrum Agile

1/62

Scrum Agile


2/62

2/10/12

1

Scrum Agile Workshop

1

By

M. Rajamanickam

Certified Scrum Master,Scrum Practitioner,

SCAMPI Lead Appraiser,

([email protected])

Managing Partner,

ProXL Consulting, Chennai, India 600 101

Workshop Backlog

Traditional Software Development Introduction to Agile Introduction to Scrum Framework

Scrum Roles Starting Scrum Product Backlog Story Points Scrum Estimation


3/62

2/10/12

2

Workshop Backlog

Sprint Planning Release Planning Scrum Ceremonies

Daily Scrum Sprint Review

Sprint Retrospection Release Planning

Benefits of Scrum Challenges of Implementing Scrum Closing session

Ground Rules

Be on time One conversation at a time Electronics by exception

Participate fully - share your thoughts &experiences

Do not reserve your questions at any time Anything else?


4/62

2/10/12

3

Software Engineering

the application of a systematic,

disciplined, quantifiable approach to

development, operation and

maintenance of software: that is, the

application ofengineering to

software.

IEEE Standard Computer Dictionary

The Traditional Development

Time

Analysis

Design

Coding

Testing


5/62

2/10/12

4

The Traditional Development -Assumptions.

IEEE Software Engineering is a good fit when:

Customer knows all requirements upfront Requirements are stable Technology is well known and mature The problem has been solved before Everything goes as per plan

How often is this true?

Weakness

All good ideas should come in the beginning, agood idea at the release stage is a threat

Emphasis on writing things down leads to lackof clarity in thought and understanding

Last minute correction not possibleUnanticipated technical problems may lead to

collapse in the model

Rigid change resistant process leads tomediocre products.

8


6/62

2/10/12

5

The Traditional Process

Time

Analysis

Design

Coding

Testing(The costof changeincreases)

Time

The Traditional Process

Time

Analysis

Design

Coding

Testing(The costof changeincreases)

Do we have halfa solution yet?


7/62

2/10/12

6

Legacy of waterfall Model

Ask Customers what they want When they really dont know

Reward them for thinking everything upfrontAnd manage that as scope

Penalize them for adding things later Do strict scope control

The result is over production of features

11

Features of traditional software!

12

* Standish Group Chaos Report 2000


8/62

2/10/12

7

Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right,

we value the items on the left more.

13http://agilemanifesto.org/

Agile Principles

Early and continuous delivery of working software in small batches

Working software is the primary measure of progress Focus on customer value Welcome changing requirements Business and developers work together Face-to-face conversation is most efficient Build projects around motivated team Self-organizing teams deliver the best solutions Sustainable development The team reflects at regular interval

14


9/62

2/10/12

8

The Agile Process

Time

Analysis

Design

Coding

Testing

The Agile Process

Time

Analysis

Design

Coding

Testing


10/62

2/10/12

9

The Agile Process

Time

Analysis

Design

Coding

Testing

20% done(100% usable!)

The best way to manage scope is

to write less code!

Develop 20% of the futures thatdeliver 80% of value

Develop and deploy highestpriority first

Stop when you run out of timeor money

Agile Methods

Scrum Extreme ProgrammingAdaptive Software Development (ASD) Dynamic System Development Method (DSDM) Feature Driven Development (FDD) Lean Software Development Lean/Kanban

18


11/62

2/10/12

10

The Agile Way!

20


12/62

2/10/12

11

What is Scrum?

Scrum is a framework for developingcomplex products and systems. It is

grounded in empirical process and

control theory. Scrum employs an

iterative and incremental approach to

optimize predictability and control risk.- Ken Schwaber

21

History of Scrum

1995a. Analysis of common software development processes not

suitable for empirical, unpredictable and non-repeatableprocesses

b. Design of a new method: Scrum by Jeff Sutherland and KenSchwaber

c. Enhancement of Scrum by Mike Beedle and combination ofScrum with extreme programming

1996Introduction to Scrum at the OOPSLA conference

2001Publication of the Agile Software Development with Scrumby Ken Schwaber and Mike Beedle 22

Mike Beedle JeffSutherland

Ken

Schwaber


13/62

2/10/12

12

Scrum

Increase speed of development

Align individual and corporate objectives

Create a culture driven by performance

Support shareholder value creation

Achieve stable and consistent communication of

performance at all levels

Enhance individual development and quality of life

23

Scrum is designed to add energy, focus, clarity, and

transparency to project planning and implementation. It will:

Scrum Overview

24


14/62

2/10/12

13

SCRUM Overview

25

26

Product Owner decides what should be produced so as toachieve success

Gets inputs from end users, team managers, stakeholders,executives, industry experts etc

Produces the product backlog which contains the features of theproduct to be produced in order of priority


15/62

2/10/12

14

27

The Product Backlog is the single master list of features,

functionality etc prioritized based on business value and risk

The Product Backlog is constantly being revised by the ProductOwner, to maximize the business success of the teams efforts.

28

Ideally consists of 7+/- 2 peopleThe team has to be cross functional containing members fromthe different verticals required for developing the productThe team is self organizing and self managing makes acommitment and manages its responsibilities


16/62

2/10/12

15

29

Sprint is referred to the fixed period of time the team commits towork in course of developing the product

The length of the sprint is decided by the Team and the ProductOwner

Working at a sustainable pace is important to avoid burn out

30

Before each Sprint, the team selects what it will commit to deliver by

the end of the Sprint.

The team creates a task-level plan for how they will deliver. The team works together to create an initial assignment of tasks,

and compares total estimated task hours with total estimated

available hours, to make sure the commitment is reasonable.

Everyone on the team takes part, regardless of experience-level


17/62

2/10/12

16

31

During the Sprint, what the team committed to deliver does not

change, and the end-date of the Sprint does not change.

This enables team to make and keep commitments, it gives theteam focus and stability during the Sprint, and it trains Product Owner

to clearly think through what is on the Product Backlog.

If something major comes up, Product Owner can direct the team to

terminate the Sprint prematurely, and start a new one.

32

In return for not making changes during the Sprint, Product Owner

can make any changes they want to the Product Backlog before

the start of the next Sprint. Product Owner can add, remove, reorder, or change items. They

can also ask the team to re-implement work thats already been

completed.


18/62

2/10/12

17

33

Each day, the team has a short meeting to update each other on

progress and surface blocks. They stand up, to keep it fast.

To keep the meeting to


19/62

2/10/12

18

35

The ScrumMaster is a new role. It can be played by an existing

person (such as a former Project Manager or team-member).

The ScrumMaster serves the team (helping them remove any andall impediments that surface), protects the team (from any outside

disruption or interference), and teaches and guides the

teams use of Scrum.

Without a ScrumMaster, the team has a high risk of failure.

36

The aim for the team is to complete 100% of what they committed

to, ideally an increment of Potentially Shippable Product at the end

of each Sprint. For software, this means functionality that has been designed,

fully implemented, and fully tested, with no major defects.

Few teams can do product Potentially Shippable Product from

Sprint 1, but each Sprint they work to get closer to this goal.


20/62

2/10/12

19

37

At the end of the Sprint, the Product Owner, Team, ScrumMaster,

and Stakeholders come together and see a demo of what the team

has produced. The Product Owner gathers feedback from everyone on ways to

improve whats been built.

This feedback is incorporated into the Product Backlog.

38

The Team, Product Owner, and ScrumMastermeet at the end of

each Sprint to review their way of working, and look for ways to

improve their effectiveness. This is the mechanism for continuous improvement, and also

where critical problems are identified and addressed, or surfaced to

management for assistance


21/62

2/10/12

20

Outline

It is an iterative, incremental framework Sprints cycles of work developed, duration 1 - 4

weeks; occur one after anotherwithout pause

Timeboxed they end whether or not the work endsAt the beginning, cross-functional team forms the

priority list based on customer requirements

During the sprint the chosen items do not change

Everyday inspection and adjustment End of the sprint, review with stakeholders Feedbacks are taken and incorporated into the sprint End of sprint, fully tested product is formed as per

customer requirements

39

Scrum Values

40

CommitmentFocusOpennessRespectCourage

Scrum asks you to committo a goaland then provides you with the authority tomeet those commitments. It insist that you

focusall your efforts on the work yourecommitted to and ignore anything else.

Opennessis prompted by the facteverything about a scrum project is visible

to everyone. Scrum tenets acknowledge

that the diversity of team membersbackground and experience adds value to

your project. Finally,

Scrum asks you to have couragetocommit, to act, to be open and expect

respect.


22/62

2/10/12

21

Components of Scrum

Scrum Roles

Ceremonies

ScrumArtifacts

41

The Product Owner The Team

42


23/62

2/10/12

22

Story

Ham and Eggs Restaurant

PIG having second

thoughts because hewould be really

committed, but the

CHICKEN would be

only be involved.43

Product Owner

Maximizing ROI Identify product features Forming the priority list Forming list for next sprint Refining the list Has profit loss responsibility of the product Interacts with the team regularly, reviews the

result and offers inputs and priorities

Only one person can be the product owner

44


24/62

2/10/12

23

The Team

Builds the product as indicatedby the Product Owner

cross-functional it includesall the expertise necessary todeliver the potentially shippableproduct each Sprint

self-organizing (self-managing) - with a very highdegree of autonomy andaccountability.

decides what to commit to, andhow best to accomplish thatcommitment.

45

Normally contain 7+ or 2people

Develops the product andgives ideas to the product

ownerAvoid multi-tasking, avoid

member changing

One team normally does allthe work - planning,

analysis, programming, and

testing 46

The Team


25/62

2/10/12

24

Scrum Master

Change Agent, a Servant LeaderHelps the team to learn and apply Scrum to get

business value

Not the managerServes on the team and protects the team from

outside interferences, educates and guides the

Owner and the team on the use of Scrum

Makes sure everyone understands and followsthe practices of Scrum

47

Scrum Master

Scrum makes visible several threats, ScrumMaster has to be energetically involved in

resolving those.

Should have a dedicated Scrum Master,from any discipline Engineering, Design,

Testing, Product Management, Project

Management, or Quality Management.

They facilitate the process, supporting theTeam as it organizes and manages itself.

No role of project manager in Scrum,traditional responsibilities of a project

manager have been divided up and

reassigned among the three Scrum roles. 48


26/62

2/10/12

25

NANNY

(Assigningtasks, getting

status reportsetc.)

GURU

(mentoring, coaching,helping remove

obstacles, helping

problem-solve,providing creative

input, and guiding theskills development of

Team members

Role of Scrum Master

Managers may need to change their management style; for example, using Socratic

questioning to help the Team discover the solution to a problem, rather than simplydeciding a solution and assigning it to the Team.

Previously

49

Functional Managers (Team Friends)

Their role changes in Scrum, they remain valuable. Forexample:

they support the Team by respecting the rules and

spirit of Scrum

they help remove impediments that the Team andProduct Owner identify

they make their expertise and experience available

50


27/62

2/10/12

1

1

12 Step Plan

1. Agree on the Product Owner, Scrum Master and Scrum Team2. Declare the Product Vision3. Define the Prioritized Product Backlog4. Estimate the Product Backlog items through relative sizing5. Set a deadline for Sprint demo, Review and retrospective Meeting

(and send invites)6. Conduct Sprint Planning Meeting to determine the resources, tasks

and detailed estimate for Spring Backlog7. Commit as a team to the sprint8. Track daily activities and impediments through Scrum Review

Meeting9. Track progress with Burndown Chart10. Conduct Sprint Demo, Review & Retrospection11. Apply recommendations to the next Sprint12. Go to Step 5

2


28/62

2/10/12

2

Starting Scrum

Product Owner generates a prioritized list of features called ProductBacklog articulates the product vision

exists (and evolves) over the lifetime of the product- road map Everything that could be done by the Team ever, in order of priority. Single Product Backlog Product Owner makes decisions keeping in mind the interest of

stakeholders & the team. Product Backlog - continuously updated by the Product Owner; for

changes inthe needs of the customer

new ideas or insights

moves by the competition

technical hurdles that appear etc.

The Team gives estimates of the effort required for each item on theProduct Backlog.

3

Product Backlog

Items in the backlog vary in size.Large ones are broken down, small ones are consolidatedProduct Backlog for upcoming Sprints - small and fine-grained , understood bythe Team, ensuring commitments; this is called an actionable size.State what is important in the least amount of space necessary.Low priority items - coarse grained or large, have less requirements details.High priority and fine-grained items that will soon be implemented tend to havemore detail. 4


29/62

2/10/12

3

Product Backlog

Product Backlog is neverdone

Product Backlog Evolvesover time

5

Product Backlog

It is impossible to know all requirements inadvance.

Wegners Lamma, 1995Uncertainty is inherent and inevitable in

software development processes and products. Zivs Uncertainty Principle

For a new software system the requirementswill not be known until after the users have

used it

Humpreys Requirements Uncertainty Principle

6


30/62

2/10/12

4

So What Do We Do?

Acknowledge that requirements emerge Show software to users Progressively refine our understanding of the product Invest time and money only in high priority features

7

Product Owner owns Product

Backlog Collectively, the developers have a sequence in which they

would like to implement the features, as will the customer.

Customers can not prioritize without some information fromthe development team, however, so it is up to the

development team to provide information (assumptions,constraints, alternatives) to the customer in order to help her

prioritize the features.

When there is a disagreement to the sequence, thecustomer wins. Evert time.

Source: Mike Cohn, User Stories Applied

8


31/62

2/10/12

5

User Stories

seek to combine the strengthsof written and verbal communication,

where possible supported by a picture.

9

What is a User Story?

A concise, written description

of a piece of functionality

that will be valuable to a user

(or owner) of the software.


32/62

2/10/12

6

User Story Cards have 3 parts

1. Card - A written description of the user story for planningpurposes and as a reminder

2. Conversation - A section for capturing further information aboutthe user story and details of any conversations

3. Confirmation - A section to convey what tests will be carriedout to confirm the user story is complete and working as

expected

User Story Description

As a [user role] I want to [goal]

so I can [reason]

Forexample:

AsaregistereduserIwanttologinsoIcanaccesssubscriber-onlycontent


33/62

2/10/12

7

User Story Description

Who (user role) What (goal)

Why (reason) gives clarity as to why a feature is useful can influence how a feature should function can give you ideas for other useful features

that support the user's goals

User Story Example: Front of

Card


34/62

2/10/12

8

User Story Example: Back ofCard (acceptance Criteria)

How detailed should a User Story be?

Detailed enough for the team to start work from,

and further details to be established and clarified

at the time of development.


35/62

2/10/12

9

INVEST in Good User Stories

Independent User Stories should be as independent as possible. Negotiable User Stories are not a contract. They are not detailed

specifications. They are reminders of features for the team to discuss

and collaborate to clarify the details near the time of development.

Valuable User Stories should be valuable to the user (or owner) ofthe solution. They should be written in user language. They should be

features, not tasks.

Estimatable User Stories need to be possible to estimate. Theyneed to provide enough information to estimate, without being toodetailed.

Small User Stories should be small. Not too small. But not too big. Testable User Stories need to be worded in a way that is testable,

i.e. not too subjective and to provide clear details of how the User

Story will be tested.

Examples: User Stories

Story 10:

o As a User I would like my search results to be paginatedso that I do not have to scroll through a long list of items

Story 22:

As a customer, I want to check my order status

online so that I can know when to expect mypackage.


36/62

2/10/12

10

Confirmation ThroughAcceptance Criteria

Product Owner makes first pass at Acceptance Criteria before SprintPlanning Meeting.

During Sprint Planning, Acceptance Criteria are discussed. Final Acceptance Criteria for each User Story is a negotiation between

Delivery Team and Product Owner

Should be short, easy to understand statements.Story 22:

As a customer, I want to check my order status

online so that I can know when to expect mypackage.

Acceptance Criteria:

1. View status as Waiting for pickup, en route, ordelivered

2. Date of each step in route3. Estimated time of Delivery

Confirmation Through

Acceptance CriteriaStory 12:

As a user, I want to be able to

pick and choose resources frommultiple pages and then save so

that I can save time .Acceptance Criteria:

1.

The user selects one, or many or allresources from any results page.

2. The users selection (checked items) persistas the user navigates from page to page.

3. The user can choose to save at any time, inwhich case all of the selected items, across

the pages, re saved.

4. If user does not click on any result andclicks Save then it saves resources only

the current page

5. If the user selects something in any of theresults pages and clicks save on any of the

pages, it saves only the selected results

Story 115:As a user, I want to perform

standards based keyword searchso that I can access a list of my

state standards correlated with thatkey word term.

Acceptance Criteria:2 User enters keyword3 User selects standards search4 System displays list of state standards

for the key word5 The state is pulled from the users

preference setting.

* Story Id 120 must precede this story to

build standards home page frompreference setting. Make sure it

includes the building of the home page


37/62

2/10/12

11

User Stories Summary

User Stories combine written and verbal communications,supported with a picture where possible.

User Stories should describe features that are of value tothe user, written in a users language.

User Stories detail just enough information and no more. Details are deferred and captured through collaboration

just in time for development.

Test cases should be written before development, whenthe User Story is written.

User Stories should be Independent, Negotiable, Valuable,Estimatable, Small and Testable.

Definition of Done

22


38/62

2/10/12

12

What is the Definition of Done?

The Definition of Done applies to all stories It states the deliverables that accompany

each Product Backlog Item.

Usually defines where items can be reviewedDefinition of Done vs Acceptance Criteria:

Definition of done helps us build the thing right

Acceptance Criteria helps us build the rightthing

Definition of Done

You need to define for your environmentDefinition will evolve over timeExample:

Unit tests written and passedAcceptance tests automated and passed User facing documentation written Checked in to the build No defects introduced


39/62

2/10/12

13

Scrum Estimation

25

Scrum Estimation

The team doing the job should estimate the projectinvolving everybody who contributes towards the project.

Break up the requirements into user stories - descriptionof a given functionality which make sense to a user.

Example:As a user I should be able to search using the following

parameters and my search results should be sortable etc. Every body comes with a set of points to estimate the

project. Points denote three aspects:

effort involved, uncertainty involved, complexity involved

After everybody rates, study the variation and question it.Record the assumptions and come to a consensus.

Estimation will vary based on who is doing it and for whomits being done.

26


40/62

2/10/12

14

Product Owner gives a business value estimate to eachindividual item. This is usually an unfamiliarpractice.

With the estimate of effort+value+risk = prioritize backlog tomaximize ROI

Estimates can be refreshed each Sprint therefore there is acontinuous re-prioritization activity

No tools or techniques for estimation and prioritization Estimate in terms of relative size Over time the team decides the extent of work per sprint and

projects a release date based on average working (velocity)

Scrum Estimation

27

Example

Estimate the size of each Product Backlog Item by Planning Poker.

SIZE = Effort x Complexity x Uncertainty

Planning Poker to estimate the Product Backlog

everyone reads the product backlog item Each person picks up the size estimate relative to the product item that has

already been estimated. Normally this is the smallest estimate in the

product

Everyone shows the card at the same time If there is a significant variation in the estimates, then high and low are

explained

Repeat the process up to 3 times until estimates stops to converge pick anumber that everyone agrees to

2. Total the Product Backlog Estimation and you get the total of size. Say in our

example, the total is 300 i.e full list = 300

3. Consider the teams velocity as 26 per sprint

28


41/62

2/10/12

15

4. Whole backlog would take 300/26 = 11.53 Sprints

5. Add Estimation buffer of 10 to 15% depending on yourcomfort less on the estimates. In our example we consider15% Estimation buffer

15% Estimation Buffer = 15% of 11.53 = 1.73

6. Add rework buffer of 10% as you would expect to have somerework

10% Rework Buffer = 10% of 11.53 = 1.15

7. Add additional buffer of 10% to cover any risks

10% Additional Buffer = 10% of 11.53 = 1.15

8. Add 1 sprint as Pre-Release Sprint

9. Total Sprints needed for the project = 11.53 + 1.73 + 1.15 +1.15 + 1 = 16.56 ~ 17 Sprints

10. You would need 17 Sprints for a Product Backlog of Size300, and team operating at a velocity of 26 per sprint.

29

Example

Spring Planning Meeting

Sprint Planning

Meeting

Product Backlog

Team Capabilities

Business Conditions

Technology

Current Product

Sprint Backlog

Sprint Goal


42/62

2/10/12

16

Sprint

A month-long iteration, during which isincremented a product functionality

NO outside influence can interfere with theScrum team during the Sprint

Each Sprint begins with the Spring PlanningMeeting

Sprint Planning

Sprint Planning Part One Sprint Planning Part Two

The Product Owner, Teamand ScrumMaster reviewthe Product Backlog

Discuss the goals for theSprint

Review the Definition ofDone*

Focuses onunderstanding what theowner wants

At the end of Part Oneproduct owner may leavealthough must always be

available

Focuses on detailed taskp l a n n i n g f o r ho w t o

implement the items thatthe Team decides to take

on.

The Team selects theitems from the ProductBacklog they commit tocomplete by the end of the

Sprint.

The Team decides howmuch work it will commit to

complete, rather thanhaving it assigned to them

by the Product Owner -

more reliable* Done means coded to standards, reviewed, implemented with unit test-driven development (TDD), tested with 100 percent test

automation, integrated, and documented.32


43/62

2/10/12

17

Estimate the teams capacityfor the upcoming sprint

Decide on the productbacklog items for the currentsprint through discussions

Decompose the ProductBacklog items into individualtasks and allocate these to

the team utilizing theircapacity. This document iscalled the Sprint Backlog

At the end , the Team willhave produced a list of allthe tasks with estimates

Scrum encourages multi-skilled workers. Team

members work together andlearn new skills from each

other.

Team members volunteer forone task at a time and

choose tasks that will onpurpose involve learning

Many Teams also make useof a visual task-tracking tool,for ex: a task board wheretasks are labeled as NotYet Started, In Progress,

and Completed.

Once the Team makes itscommitment, any additions

or changes must be deferreduntil the next Sprint.

Under externalcircumstances that change

priorities, the Product Owneror the Team can terminate

the Sprint.

33

Teams Benefit

First, the Team gets to work knowingwith absolute certainty that its

commitments will not change, that

reinforces the Teams focus onensuring completion.

Second, it disciplines the ProductOwner into really thinking through theitems he or she prioritizes on the

Product Backlog and offers to the

Team for the Sprint.

34


44/62

2/10/12

18

Product Owners Benefit

First , he or she has theconfidence of knowing the Teamhas made a commitment tocomplete a realistic and clear setof work it has chosen.

Second, the Product Owner getsto make whatever changes he orshe likes to the Product Backlogbefore the start of the next Sprint.

At that point, additions, deletions,m o d i f i c a t i o n s , a n d r e -prioritizations are all possible andacceptable.

35

1

Pre-Project/Kickoff Meeting

A special form of Sprint Planning MeetingMeeting before the begin of the Project


45/62

2/10/12

19

Daily Scrum

A short (15 minutes or less)meeting that happens everyworkday at an appointed

time.

Everyone on the Teamattends.

To keep it brief, everyoneremains standing.

It is the Teams opportunityto synchronize their work and

report to each other onobstacles.

37

ScrumMaster resolves issues(if any) post the stand up meeting in afollow up meeting.

This follow-up meeting is a common event where the Team goesthrough the inspect and adapt cycle. Some team members mayattend.

No managers or people in authority, the team may feel monitored. Stakeholder may reach out to the Team following the meeting, and

offer to help with any blocks that are slowing the Teams progress.

In the Daily Scrum, one by one, each member of the

Team reports three things to the other members of theTeam:

(1) What they were able to get done since thelast meeting;

(2) what they are planning to finish by the next

meeting;(3) any blocks or impediments that are in their

way.

38


46/62

2/10/12

20

Updating Sprint Backlog & Sprint Burn downChart

Following this someone adds up thehours remaining for the Team as a

whole, and plots it on the SprintBurndown Chart - new estimate of

how much work (measured in personhours) remains until the Teams tasksare finished.

downward sloping graph that is on atrajectory to reach zero effort

remaining by the last dayof theSprint.

Shows the Team their progress towardstheir goal, in terms of how much workremains in the future what separates

the Team from their goal.

Every day, the Team members update their estimate of the amount of time

remaining to complete their current task in the Sprint Backlog

39

Daily Scrum

Is NOT a problem solving session Is NOT a way to collect information about

WHO is behind the schedule

Is a meeting in which team members makecommitments to each other and to the ScrumMaster

Is a good way for a Scrum Master to track theprogress of the Team


47/62

2/10/12

21

Scrum FAQs

Why daily? How does a project get to be a

year late?

One day at a time. Fred Brooks, The

Mythical Man-Month.

Can Scrum meetings bereplaced by emailed statusreports?

No Entire team sees the whole

picture every day

Create peer pressure to dowhat you say youll do

SPRINT BURNDOWN CHART

42

If the burn down line is not trackingdownwards towards completion near the end

of the Sprint, then the Team needs to adjust,

such as to reduce the scope of the work or to

find a way to work more efficiently while stillmaintaining a sustainable pace.

more effective to show it on paper on a wall intheir workspace, with updates in pen; this

low-tech/high-touch solution is fast, simple,

and often more visible than a computer chart


48/62

2/10/12

22

Burndown Chart

43

Product Backlog Grooming

Five or ten percent of each Sprint must be dedicated by the Teamto refining (or grooming) the Product Backlog.

Detailed requirements analysis, splitting large items into smallerones, estimation of new items, and re-estimation of existing items.

Conduct a focused workshop near the end of the Sprint, so that theTeam and Product Owner can dedicate themselves to this workwithout interruption.

This refinement activity is not for items selected for the currentSprint; it is for items for the future, most likely in the next one or twoSprints.

Sprint Planning becomes relatively simple because the ProductOwner and Scrum Team start the planning with a clear, well-analyzed and carefully estimated set of items.

A sign that this refinement workshop is not being done (or not beingdone well) is that Sprint Planning involves significant questions,discovery, or confusion and feels incomplete; planning work thenoften spills over into the Sprint itself, which is typically not desirable.

44


49/62

2/10/12

23

Ending the Sprint

One of the core tenets of Scrum is that the duration of theSprint is never extended it ends on the assigned dateregardless of whether the Team has completed the work itcommitted to.

Over-commitment can be compensated in the followingSprints

By the third or fourth Sprint a Team has typically figuredout what it is capable of delivering

Teams are encouraged to pick one duration for theirSprints (say, two weeks) and not change it. This helps theTeam learn how much it can accomplish, which helps inboth estimation and longer term release planning.

It also helps the Team achieve a rhythm for their work; thisis often referred to as the heartbeat of the Team inScrum.

45

Sprint Review

Attended by the Team, the Product Owner, Scrum Master,customers, stakeholders, experts, executives, and anyone elseinterested.

The team provides a presentation of the extent of completion ofwork and comparison to the estimate as per the backlog.

Complete transparency is maintained during this process. A key idea in Scrum is inspect and adapt. To see and learn what

is going on andthen evolve based on feedback, in repeatingcycles.

Product Owner learns how much of the product is beingdeveloped

Team learns what are the changed requirements of theproduct in the market

Scrum Master defines done and items which are not doneare prioritized and put back on the product backlog

46


50/62

2/10/12

24

Sprint Retrospective

Follows the Sprint Review, itinspects and adapts the process

Provides an opportunity for theteam to decide on whats workingand whats not and to agree on achange in strategy.

Attended by the Scrum Master andthe team but is optional for the

product owner.

Facilitated by an outsider to get adifferent perspective even over theScrum Masters ability to managethe team

47

The Approach

Whats working Whats not

The team populates the above table

Common items become clear

Look for underlying causes and the changes are implemented in the next sprint

Items are classified as C caused by the Scrum or E exposed by the Scrum or

U unrelated to the Scrum

A lot of C on the Whats working side and a lot of E on the Whats not

working side is a good sign because the first step to solving underlyingissues is making them visible, and Scrum is a powerful catalyst for that

48


51/62

2/10/12

25

Updating Release Backlog and BurndownChart

At this point, some items have been finished, somehave been added, some have new estimates, andsome have been dropped from the release goal.

Product Owner is responsible for ensuring that thesechanges are reflecting in the Release Backlog

In addition, Scrum includes a Release Burndownchart that shows progress towards the release date.

It is analogous to the Sprint Burndown chart, but is atthe higher level of items (requirements) rather thanfine-grained tasks.

Since a new Product Owner is unlikely to know whyor how to create this chart, this is another opportunityfor a ScrumMaster to help the Product Owner.

49

Release Backlog Chart a subset of the Product

Backlog Chart50


52/62

2/10/12

26

Release Burndown Chart

Will the release be done on right time?X-axis: sprintsY-axis: amount of hours remainingThe estimated work remaining can also burn

up

Release Burn down Chart

Is a big picture view of projects progress (all the releases)


53/62

2/10/12

27

Starting the next Sprint

Following the Sprint Review, the Product Ownermay update the Product Backlog with any newinsight.

The Product Owner and Team are now ready tobegin another Sprint cycle.

No down time between Sprints Teams normallygo from a Sprint Retrospective one afternoon intothe next Sprint Planning the following morning (orafter the weekend).

One of the principles of agile development issustainable pace, and only by working regularhours at a reasonable level can Teams continuethis cycle indefinitely

53

Release Sprint

Product should be potentially shippable at the end of eachSprint no wrapping up, testing or documentation isrequired post the Sprint

Each increment is a complete slice of the final product full transparency to the Product Owner and stake holders

Weak development practices, tools and infrastructure result in delay of the work in each Sprint

In such cases there will be the need for a Release Sprintto handle this remaining work.

Release Sprints indicate a sign of weakness If the Team has followed good development practices, with

continuous refactoring and integration, and effectivetesting during each Sprint, there should be little pre-release stabilization or other wrap-up work required.

54


54/62

2/10/12

28

A new product

In the case of a new product, or an

existing product just adopting Scrum,

There is the need to do initial ProductBacklog refinement before the first

Sprint, where the Product Owner and

Team shape a proper Scrum ProductBacklog.

This could take a few days or a week,and involves a vision workshop, some

detailed requirements analysis, andestimation of all the items identified for the

first release.

55

TATA NANO

An existing product

The Product Owner and Teamshould be doing Product Backlogrefinement every Sprint (five orten percent of each Sprint),continuously preparing for thefuture.

T h i s c o n t i nu o u s p r o d u c t development mode obviates the

n e e d f o r t h e d r a m a t i c punctuated prepare-execute-conclude stages one sees intraditional sequential life cycledevelopment.

56

TATA INDICA V2


55/62

2/10/12

29

Release Planning and Initial Product BacklogRefinement

During an initial Product Backlog refinement workshop and during the

continuous backlog refinement of each Sprint, the Team and Product Owner willdo release planning, refining the estimates, priorities, and content as they learn.

Date driven releases Road Map One time release

57

Date driven releases

The Team will complete as many Sprints (andbuild as many features) as is possible in the timeavailable.

Other products require certain features to be builtbefore they can be called complete and the

product will not launch until these requirementsare satisfied, however long that takes.

Since Scrum emphasizes producing potentiallyshippable code each Sprint, the Product Ownermay choose to start doing interim releases, toallow the customer to reap the benefits ofcompleted work sooner.

58


56/62

2/10/12

30

Road Map

The team and the Product Owners cannotpossibly know everything up front

The focus is on creating and refining a plan togive the release broad direction, and clarify

how tradeoff decisions will be made (scope

versus schedule, for example).

It is like a roadmap guiding you towards yourfinal destination; which exact roads you take

and the decisions you make during the

journey may be determined en route.59

One time release

will decide a release date, and will work withthe Team to estimate the Release Backlog

items that can be completed by that date.

In situations where a fixed price / fixed date /fixed deliverable commitment is required for example, contract development one or

more of those parameters must have a built-

in buffer to allow for uncertainty and change

60


57/62

2/10/12

31

Application or Product Focus

Scrum focuses on a Continuous application/product developmentmodel. There is no longer a project with a beginning, middle, andend.

There is simply a stable Product Owner and a long-lived self-managing Team that collaborate in an endless series of fixed-length Sprints, until the product or application is retired.

project management work is handled by the Team and theProduct Owner who is an internal business customer or fromProduct Management.

Scrum can also be used for trueprojects that are one-timeinitiatives (rather than work to create or evolve long-livedapplications); still, in this case the Team and Product Owner do theproject management.

Occasionally, there is insufficient new work even for the priorsolution, and the Team may take on items from several applicationsduring the same Sprint; however, beware this solution as it maydevolve into unproductive multitasking across multiple applications.

A basic productivity theme in Scrum is for the Team to be focusedon one product or application forone Sprint. 61

Failure of Scrum

Application of Scrum isone thing but when do we

know that the Scrumprocess is not working?

Failure of Scrum does notoccur because of onereason, it occurs due tovariety of reasons

including:

62


58/62

2/10/12

32

Emotional

Symptoms: Individualopposition, Confusion,

Subversive Behavior, No

Discipline, Apathy

Root Cause: Fear, Influence,Preference, Superiority,

Ignorance, Indifference,Position, Comfort

63

Cultural

Symptoms: Micromanagement, Mini-Waterfalls, Finger-Pointing, Revoking

team discussions, detailed reporting,scrum master is seen as accountable

for the team

Root Cause: Heroism, command &control, bad values, limited

accountability, hierarchical thinking,

individual compensation, blaming,

compliance

64


59/62

2/10/12

33

Reflections

Symptoms: Process in sprint issame as Sprint 1, no known Sprintvelocity, no hands-on customerdemo, no code reviews, stand-upmonotonous, test and run beforecheck-in

Root Cause": Misleading metrics,no group reflections, missing selfreflection, missing commitment,non-learning, wrong valuedefinition, comfort zone

65

Adaptations

Symptoms: Retrospectivewithout actions, no time for

change, do things that do not

work again and again, no

refactoring, sprint review without

consequences, still no tests

Root Cause: ineffective scrummaster, cookie cutter process,

imposed process, group

pressure, invisible product

owner, no empowerment, no

adaption, too frequent changes.

66


60/62

2/10/12

34

Collaboration

Symptoms: Task handover, manyloose ends, only business analyst

talks to the customer, no team

planning, not slowing down for

teammates, deciding for customer,

check-in race

Root Cause: Segregation, hard-coded communication paths, push-systems, no shared responsibility,

separation, turf wars and politics.

67

Pros/Cons

Advantages Completely developed

and tested features in

short iterations

Simplicity of theprocess

Clearly defined rules Increasing productivity Self-organizing each team member

carries a lot of

responsibility

Improvedcommunication

Combination withExtreme Programming

Drawbacks Undisciplined

hacking (no written

documentation)

Violation ofresponsibility

Currently carried mainlyby the inventors


61/62

2/10/12

35

Benefits of SCRUM

Improvement Statistics: Productivity Improvement 68% Team Morale 52%Adaptability 63%Accountability 62% Collaboration and Cooperation 81%

69

Challenges of SCRUM

Inability to get everyone involved with planning Failure to have dedicated roles Scrum Master,

Product Owner and Team

Product Owner that isnt ready for the team Teams lacking authority and decision-making ability Ineffective use of the retrospection Obtaining only checkbook commitments from

executive management

Failure to pay attention to infrastructure required Reverting to formA culture that does not support learning

70


62/62

2/10/12

References

Some good websites on Scrum: www.scrum.org www.scrumalliance.com www.jeffsutherland.com www.mountaingoatsoftware.com

Suggested readings:Agile Software Development with Scrum, Ken

Schwaber and Mike Beedle

Agile Project Management with Scrum, KenSchwaber

User Stories Applied, Mike CohnAgile Estimating and Planning, Mike Cohn 71

Questions, Comments, Concerns?

M. Rajamanickam([email protected])

Managing Partner,

Book 1_Scrum Agile

Documents