Scrum - A Short Tour

Scrum – A Short Tour
By:
Vineet Patni
PMP, PMI-ACP, PMI-PBA, SPC, CSP, CSM, CSPO
www.ScaleUpConsultants.com

https://in.linkedin.com/in/patnivineet
https://twitter.com/patnivin
https://in.linkedin.com/in/patnivineet
https://twitter.com/patnivin
ScaleUp
Vineet Patni
Facilitator-Coach-Speaker-Writer
Vineet Patni
Facilitator-Coach-Speaker-Writer

© 2014, Scale Up Pvt. Ltd.
3 3
 The Agile Manifesto & Principles
 The Agile Umbrella
 Scrum Process
 Scrum Roles
 Scrum Events
 Scrum Artifacts
Scrum

44
The Agile Manifesto
in February , 2001
• Kent Beck
• Mike Beedle
• Arie van
Bennekum
• Alistair Cockburn
• Ward
Cunningham
• Martin Fowler
• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries
• Jon Kern
• Brian Marick
• Robert C. Martin
• Steve Mellor
• Ken Schwaber
• Jeff Sutherland
• Dave Thomas
source: www.agilemanifesto.org
source: http://agilemanifesto.org

55
Agile Principles
source: http://agilemanifesto.org

66
Agile Principles…
Satisfy
Customer
Harness
Change
Deliver
Frequently
Work
Together Daily
Motivated
Individuals
Face-to-Face
Conversation
Measure
Working
Software
Sustained
pace
Technical
Excellence
Keep it simple
Self
Organizing
Teams
Reflect-Tune-
Adjust

77
The Agile Umbrella
source: http://www.agigante.it/scrum-and-agile-synonyms-and-other-agilemethodologies/

© 2014, ScaleUp Training and Consulting
8
Scrum

99
 A scrum (short for scrummage) is a method of restarting play
in rugby.
 The players pick the ball and sprint towards the goal post.
Scrum…

1010
What is Scrum?
 A process framework for developing
complex software products
 Lightweight
 Simple to understand
 Difficult to master
 Scrum’s NOT a process or a
technique for building products

1111
The Scrum Process
source: http://www.supraliminalsolutions.com/

1212
Scrum – Key Characteristics
 One of the Agile methodologies
 Requirements are captured as items in a
list of “product backlog”
 Product progresses in a series of month-
long “sprints”
 No specific engineering practices
prescribed
 Self-organizing teams

1313
The Scrum Theory
 Empirical process control theory
 Knowledge comes from experience
and observation, and making
decisions based on what is known.
 An iterative, incremental approach to
optimize predictability and control risk.

1414
3 Pillars of Scrum
Transparency:
Giving visibility to the
significant aspects of the
process to those responsible
for the outcome.
Adaptation:
Adjusting a process as soon as
possible to minimize any
further deviation or issues.
Inspection:
Timely checks on the progress
toward a Sprint Goal to detect
undesirable variances.

1515
Scrum Values

1616
Scrum provides a common vocabulary
Product Backlog:
All work to be performed in the foreseeable future, both well-defined and
requiring further definition.
Sprint:
A period of 30 days of less where a set of work will be performed to create a
deliverable.
Sprint Backlog:
That work that is well enough defined that it can be worked on with relatively
little change over a period of 30 days or less and will result in a tangible,
incremental deliverable.
Daily Scrum:
A daily meeting at which progress and impediments to progress is reviewed.
Scrum provides a common language for the common sense way of
organizing, performing, and managing work.

1717
What’s all in Scrum…
 The Scrum Process
 Scrum Roles
 Scrum Events
 Scrum Artifacts
It’s all in a “Sprint”
 Sprint is the heart of Scrum.
 Time-box of one month or less.
 Work is done during a Sprint, , and
Product Increment is created.
 Constant duration brings in development
cadence.

1818
Sprint
 Time-box of one month or less, during which..
 The product is designed, coded and tested,
and..
A “Done”, useable, and potentially releasable
Product Increment is created.
 Sprints are of consistent duration during a
Development effort, and placed back-to-back.

1919
During a Sprint…
No changes are made that would endanger
the Sprint Goal.
 Scope may be clarified and re-negotiated
between the Product Owner and
Development Team.
Plan sprint durations around how long you can
commit to keeping change out of the sprint

2020
Cancelling A Sprint…
 Sprint can be cancelled before the Sprint
time-box is over if the Sprint Goal becomes
obsolete.
 Only the Product Owner has the authority
to cancel the Sprint.

212121
Scrum Roles

2222
Scrum Roles
source: https://www.safaribooksonline.com/library/view/the-professional-scrummasters/9781849688024/ch01s04.html

2323
Scrum Roles...
source: https://hoangluongsjsu.wordpress.com/2014/09/21/the-agile-team-and-what-is-a-backlog-what-are-they-for-and-why-are-
they-important/

2424
Product Owner
Responsible for maximizing the ROI - value of the product
 Customer Representative – Final authority
representing the customer's interest Manages the
Product Backlog (prioritization and clarifying
requirements)
 .. is a sole person, not a group or committee
 Accepts or rejects deliverables created by the team
 Must be "available" to the team at any time
 Facilitates the Sprint review meeting
 Must resist the temptation to “manage” the team
or the team’s work
 Must not try to add more work while the Sprint is in
progress.
 Balance the interests of all stakeholders

2525
Product Owner…
source: https://agilefaq.wordpress.com/2012/08/12/what-does-a-scrum-product-owner-do/

2626
Development Team
Responsible for delivering a
potentially shippable
increment of working software
 Anyone working on sprint
tasks toward the sprint goal.
 Self-organized
 Cross-functional
 Defines practices
 5 to 9 persons
 Membership should be full-
time and change only
between sprints.

2727
Scrum Master
Responsible for in Scrum adoption and
ensures Scrum is understood and enacted
 Management Representative
 Team facilitator
 Inculcates Scrum values within team
 Coach
 Servant Leader
 Monitoring & Tracking
 Reporting & Communication
 Removes impediments
 Resolves conflicts
 Shields the team
 Team motivator

2828
Scrum Master…
source: http://illustratedagile.com/2011/12/13/the-scrum-master-performance-review-preparation/

2929
Where is the Project Manager?

303030
Scrum Events

3131
Scrum Events…
Sprint Planning
• How much of the Product Backlog?
• What can be done this Sprint?
• How will the chosen work get done?
Daily Stand-up
• 15-minute time-boxed event.. to plan for next
24 hours
• Every team member - “What did I do?”, “What
do I plan to do?” and “Where I am stuck?”
!! Sprint Goal !!
!! Commitment,
focus !!

3232
Scrum Events…
Sprint Review
• Four-hour time-boxed meeting at the end of the
Sprint
• Inspect the Increment and adapt the Product Backlog
• The Scrum Team and stakeholders collaborate about
what was done in the Sprint
Sprint Retrospective
• Two-hour time-boxed meeting after the Sprint Review
• Reflect on last Sprint with regards to people,
relationships, process, and tools
• Create Action plan for potential improvements
!! Demo !!
!! Looking back !!

333333
Sprint Planning

3434
Sprint Planning
 The work to be performed in the Sprint is planned at the Sprint
Planning.
 This plan is created by the collaborative work of the entire Scrum
Team.
 The Scrum Master facilitates the Sprint Planning meeting and
keeps it time-boxed.

3535
Sprint Planning…
 “What can be delivered in the Increment resulting from the
upcoming Sprint?“
 “How will the work needed to deliver the Increment be
achieved?”

3636
Sprint Goal
A short statement of what the work will be focused
on during the sprint
The objective set for the Sprint, created during the
Sprint Planning meeting.
Provides guidance and flexibility to the
Development Team.

3737
From Sprint Goal to Sprint Backlog
Scrum team takes the Sprint Goal and decides what
tasks are necessary
Team self-organizes around how they’ll meet the
Sprint Goal
Manager doesn’t assign tasks to individuals
Sprint Backlog is created

3838
Sprint Backlog creation…
As a …..,
I want ……..
User Story
TASK LIST
Sprint Backlog
 Task 1: Code
 Task 2: Test
 Task 3: Automate
 …..
 ….

3939
Sprint Planning…
• Product Owner
• Development Team
• Customers
• Management
Who
• To come up with the Sprint Goal
• To create the Sprint Backlog
Purpose
• At the start of each SprintWhen

404040
Daily Stand-up

4141
Daily Stand-up
The Daily Scrums are short and crisp team meetings.
Maximum 15 minutes.
These happen at the same time, same place each day.
These are not status sessions for the manager / Scrum
Master.
Not for problem solving.
They are team members’ commitments in front of the
team.

4242
 What did I do yesterday (last 24 hours)?
 What will I do today (next 24 hours)?
 What’s blocking my way (impediments)?
Each participant answers 3 questions
Are “we” on the right track to achieve our Sprint Goal
during this Sprint?
 If yes, Great!
 If no, what is holding us back?
Daily Stand-up…

434343
Sprint Review

4444
Sprint Review
Held at the end of the Sprint to inspect the Product
Increment and adapt the Product Backlog if
needed.
The Product Owner facilitates the Sprint Review.
Attendees include the Scrum Team and key
stakeholders invited by the Product Owner.

4545
Sprint Review…
The Development Team demonstrates the work
that it has “Done” and answers questions about the
Increment.
The entire group collaborates on what to do next,
so that the Sprint Review provides valuable input to
subsequent Sprint Planning.
The result of the Sprint Review is a revised and
refined Product Backlog that defines the probable
Product Backlog items for the next Sprint.

4646
Sprint Review…
• Product Owner
• Scrum Master
• Development Team
• Key, Interested Stakeholders
Who
• To demonstrate completed work
• To gather feedback
• Refine the Product Backlog
Purpose
• At the end of each SprintWhen

4747
Sprint Review…

484848

4949
“A ritual held at the end of a project to learn from
experience and to plan changes for the next effort".
Retrospectives are regular reviews of the team, by
the team, to discuss how they are working.
Focus is on the process, not the product.

5050
Sprint Retrospective…
A meeting where a team looks back on a past period
of work so that they can learn from their experience
and apply this learning to current / future projects.
 What works (clear wins)?
 What doesn’t work so well?
 What do we need to start doing?

5151
A Retrospective is NOT…
A Retrospective is not a Post-Mortem: Aim to use
Retrospectives regularly during the life of the
project rather than after catastrophic failure.
A Retrospective is not a Witch-Hunt: Retrospectives
are not about apportioning blame.

5252
Prime Directive
"Regardless of what we discover, we understand
and truly believe that everyone did the best
job they could, given what they knew at the
time, their skills and abilities, the resources
available, and the situation at hand.“
- Norm Kerth, Project Retrospectives: A
Handbook for Team Reviews

5353
Retrospective Process
1. Set the stage
2. Gather Data
3. Generate Insights
4. Decide what to do
5. Close the Retrospective

5454
1. Set the stage: Get everyone to speak. Agree on
rules. Use a safety exercise.
2. Gather data: Feelings are legitimate data!
3. Generate insights: “Why?” Begin discussing how to
do things differently.
4. Decide what to do: Commit to one to two action
items or experiments.
5. Close the retrospective: Review the retrospective
itself. Capture info. Thank all.

5555
• End of Iteration, Release or ProjectWhen
• For the team, by the team
• Not for any individual team memberWho
• Inspect and Adapt ..
• The process, not about the product.What
Sprint Retrospective…

565656
Scrum Artifacts

5757
Scrum Artifacts
• Single Source of all product requirements
• Ordered list
• Product Owner’s responsibility
• Evolves over time, never complete
Product Backlog
• Sub-set of top priority PBIs
• A Plan for delivering the product Increment
and realizing the Sprint Goal
• Only the Sprint Team can change it
Sprint Backlog
• Sum of all the Product Backlog Items (PBIs)
completed during a Sprint
• Must meet the “Done” criteria
• Minimum shippable product
Product Increment

585858
Product Backlog

5959
Product Backlog
An ordered list of everything that might be needed in
the product
The single source of all product requirements (all
features, bugs, enhancements, non-functional
requirements, etc.)
The objective of creating a Product Backlog is to
expand the product vision, through an evolutionary
requirements definition process, into a product
feature list

6060
Product Backlog…
 Product Owner is accountable for the PB and any updates to
it.
 Ordered based on risk, business value, dependencies, date
needed, etc.
 A Product Backlog is never complete, and evolves
continuously.
 The Product Backlog is dynamic, living artifact; and exists as
long as a product exists.
 All Product Backlog Item (PBI) must have a value and a size
estimate.

6161
Product Backlog……
A Product Backlog must be D.E.E.P.

6262
Sample Product Backlog

6363
Sample Product Backlog…

6464
Product Backlog Refinement
Product Backlog refinement is the act of
adding detail, estimates, and order to
items in the Product Backlog.
This is an ongoing process.
 Higher ordered Product Backlog items
are usually clearer and more detailed
than lower ordered ones.
 Product Backlog items that can be
“Done” by the Development Team
within one Sprint are deemed “Ready”
for selection in a Sprint Planning.

6565
Product Backlog Refinement

666666
Sprint Backlog

6767
Sprint Backlog
A set of the Product Backlog items selected for the
Sprint, accompanied a plan for delivering the
product Increment and realizing the Sprint Goal.
Serve’s as the Development Team’s forecast about
what functionality will be in the next Sprint.
It’s a highly visible view of the work being
undertaken and may only be updated by the
development team.

6868
Sprint Backlog…
The Sprint Backlog emerges during the
Sprint.
This emergence occurs as the Development
Team works through the plan and learns
more about the work needed to achieve the
Sprint Goal.

6969
Sprint Backlog…
Only the Development Team can change its Sprint
Backlog during a Sprint.
 As new work is required, the Development Team
adds it to the Sprint Backlog.
 As work is performed or completed, the
estimated remaining work is updated.
 Task estimates are updated whenever there’s
new information
 When elements of the plan are deemed
unnecessary, they are removed.

707070
Product Increment

7171
Product Increment
The Product Increment
is the sum of all the
Product Backlog items
completed during a
Sprint and the value of
the increments of all
previous Sprints.

7272
Product Increment…
 Each Product Increment is additive to all prior Increments and
thoroughly tested, ensuring that all Increments work together.
 At the end of a Sprint, the new Increment must be “Done,” which means
it must be in useable condition and meet the Scrum Team’s definition of
“Done.”
 It must be in useable condition
regardless of whether the Product
Owner decides to actually release it.

7373
Product Increment……
source: http://www.romanpichler.com/blog/the-definition-of-ready/

747474
So, Are we Done?

7575
Are we “Done”?

7676
Definition of Ready
 The team makes explicit and visible
the criteria that a user story must meet
prior to being accepted into the
upcoming iteration.
 The team works with the PO to agree
on what defines a “ready” state of a
backlog item.

7777
Definition of Ready… Example
 Story defined and written
 Story traceable to source document (where appropriate)
 Acceptance criteria defined
 Dependencies identified
 Size estimated by delivery team
 User experience included (where appropriate)
 Performance criteria identified (where appropriate)
 Person who will accept the user story is identified
 Team has a good idea about how to demo the user story

7878
Definition of Done (DoD)
 The definition of “Done” for the Scrum
Team is used to assess when work is
complete on the product Increment.
 A shared understanding of what it
means for work to be complete to
ensure transparency.
 The team should collectively create
the definition of done for the items
before they begin work on them.

7979
Definition of Done (DoD)
Done means “Done” if…
 It has been tested and has passed user acceptance or
client approval
 It has passed an in-house iteration review
 It is “shippable” or “deliverable”

8080
Definition of Done (DoD)… Example

8181

8282
The Scrum Framework
by: Vineet Patni

83838383
Please reach out to us with feedback at:
Vineet@ScaleUpConsultants.com
Contact@ScaleUpConsultants.com
PMP, PMI-ACP, PMI-PBA, Agile (Scrum, Lean, Kanban, SAFe, DAD)
https://www.linkedin.com/company/scale-up
https://twitter.com/ScaleUpPune
https://www.facebook.com/ScaleUpConsultants
https://plus.google.com/117837859519308773805/posts
https://www.youtube.com/channel/UCoCca2D-Wyof3fbS6vIdjRg/playlists

84848484
We are Done! 

Scrum - A Short Tour

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Scrum - A Short Tour

Ähnlich wie Scrum - A Short Tour (20)

Mehr von Vineet Patni

Mehr von Vineet Patni (15)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Scrum - A Short Tour