Transcript
8/2/2019 Book 1_Scrum Agile
1/62
Scrum Agile
8/2/2019 Book 1_Scrum Agile
2/62
2/10/12
1
Scrum Agile Workshop
1
By
M. Rajamanickam
Certified Scrum Master,Scrum Practitioner,
SCAMPI Lead Appraiser,
(mrajamanickam@gmail.com)
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
8/2/2019 Book 1_Scrum Agile
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?
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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?
8/2/2019 Book 1_Scrum Agile
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/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
9/62
2/10/12
8
The Agile Process
Time
Analysis
Design
Coding
Testing
The Agile Process
Time
Analysis
Design
Coding
Testing
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
11/62
2/10/12
10
The Agile Way!
20
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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.
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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.
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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.
8/2/2019 Book 1_Scrum Agile
22/62
2/10/12
21
Components of Scrum
Scrum Roles
Ceremonies
ScrumArtifacts
41
The Product Owner The Team
42
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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.
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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.
8/2/2019 Book 1_Scrum Agile
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.
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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)
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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
8/2/2019 Book 1_Scrum Agile
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(mrajamanickam@gmail.com)
Managing Partner,
top related