Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Book of
Knowledge
An unofficial compilation of a few scrum knowledge
sources in order to provide a comprehensive and short
description of Scrum.
Written by Illya Pavlichenko, CSM, CSPO, CSP, PSM I, PMI-ACP
Email: fancydev@gmail.com, scalestudy.com@gmail.com
January 2013, Version 1.0
Scrum Basics
Scrum is a Framework within which people can address Complex Adaptive Problems, while
productively and creatively delivering products of the highest possible value.
Characteristics:
1. Lightweight
2. Simple to understand
3. Extremely difficult to master
Scrum Theory
Scrum is founded on Empirical Process Control Theory, or Empiricism. Empiricism asserts that
knowledge comes from experience and making decisions based on what is known. Scrum
employs an Iterative, Incremental approach to optimize predictability and control risk.
Scrum is based on Transparency, Inspection, and Adaptation.
Creators of Scrum
Ken Schwaber
Jeff Sutherland
Scrum Values
All work performed in Scrum needs a firm basis of values to serve as a foundation for the team's
process and principles. Through the use of teamwork and continuous improvement, Scrum both
creates these values and relies on them.
Focus
Courage
Openness
Commitment
Respect.
Scrum Framework
Scrum Framework consists of:
1.
2.
3.
4.
Roles
Events
Artifacts
Rules that bind them together
1.1 Roles
The Scrum Team consists of:
1. The Product Owner
2. The Development Team
3. The Scrum Master
Definition of Done
Retrospective Meeting
Sprint Planning Meeting
Sprint Goal
Responsibilities:
1.
2.
3.
4.
Owns:
1. Sprint Backlog
2. Daily Scrum Meeting
3. Daily Plan
Servant-leader
Facilitator
Coach
Trainer
Teacher
Protector
Mentor
Bulldozer
Responsibilities:
1. Responsible for ensuring Scrum is understood and enacted. Scrum Masters do
this by ensuring that the Scrum Team adheres to Scrum theory, practices, and
rules
2. The Scrum Master helps those outside the Scrum Team understand which of
their interactions with the Scrum Team are helpful and which arent. The Scrum
Master helps everyone change these interactions to maximize the value created
by the Scrum Team
3. Finds techniques for effective Product Backlog management
4. Clearly communicates vision, goals, and Product Backlog items to the
Development Team
5. Teaches the Scrum Team to create clear and concise Product Backlog items
6. Understands long-term product planning in an empirical environment
7. Understands and practices agility
8. Facilitates Scrum events as requested or needed
9. Ensures that the Development Team has the Daily Scrum meeting,
10. Coaches the Development Team in self-organization and cross-functionality
11. Teaches and leads the Development Team to create high-value products
12. Removes impediments to the Development Teams progress
13. Coaches the Development Team in organizational environments in which Scrum
is not yet fully adopted and understood
14. Leads and coaches the organization in its Scrum adoption
15. Plans Scrum implementations within the organization
16. Helps employees and stakeholders understand and enact Scrum and empirical
product development
17. Causes change that increases the productivity of the Scrum Team
18. Works with other Scrum Masters to increase the effectiveness of the application
of Scrum in the organization
19. Managing Impediment Backlog (Optional)
Owns:
1. Scrum Process
2. Impediment Backlog (Optional artifact)
Duration
Time-boxed to 8 hours for
a one-month Sprint.
For shorter Sprints, the
event is proportionately
shorter.
Inputs
1. Product Backlog
2. Latest Product Increment
3. Projected Capacity of the Development
Team
4. Past Performance of the Development
Team
1.
2.
3.
4.
Attendees
Product Owner
Scrum Master
Development Team
Other people to attend in
order to provide technical
or domain advice
(Optional)
Outputs
1. Sprint Goal
2. Sprint Backlog
Rules:
The Sprint Planning Meeting consists of two parts, each one being a time-box of one
half of the Sprint Planning Meeting duration.
1. What will be delivered in the Increment resulting from the upcoming Sprint?
In this part, the Development Team works to forecast the functionality that will be
developed during the Sprint. The Product Owner presents ordered Product Backlog
items to the Development Team and the entire Scrum Team collaborates on
understanding the work of the Sprint.
The number of items selected from the Product Backlog for the Sprint is
solely up to the Development Team. Only the Development Team can
assess what it can accomplish over the upcoming Sprint.
Sprint Goal
After the Development Team forecasts the Product Backlog items it will deliver
in the Sprint, the Scrum Team crafts a Sprint Goal. Sprint Goal is an objective
that will be met within the Sprint through the implementation of the Product
Backlog, and it provides guidance to the Development Team on why it is
building the Increment. The Sprint Goal gives the Development Team some
flexibility regarding the functionality implemented within the Sprint. As the
Development Team works, it keeps this goal in mind. In order to satisfy the
Sprint Goal, it implements the functionality and technology. If the work turns out
to be different than the Development Team expected, then they collaborate with
the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.
Having selected the work of the Sprint, the Development Team decides how it will
build this functionality into a Done product Increment during the Sprint. The Product
Backlog items selected for this Sprint plus the plan for delivering them is called
the Sprint Backlog.
The Product Owner may be present during the second part of the Sprint
Planning Meeting to clarify the selected Product Backlog items and to help make
trade-offs. If the Development Team determines it has too much or too little work, it
may renegotiate the Sprint Backlog items with the Product Owner. The
Development Team may also invite other people to attend in order to provide technical
or domain advice.
Good Practices:
Duration
15-minute time-boxed
event
1.
2.
3.
4.
Inputs
1. Impediments faced
2. Information about what have
been done since the last Daily
Scrum
Attendees
Development Team
Scrum Master
(Optional, but highly
desirable)
Product Owner
(Optional)
Other people as
observers (Optional)
Outputs
1. Identified Impediments
2. Plan for 24 hours
Rules:
The Daily Scrum is held at the same time and place each day to reduce complexity
During the meeting, each Development Team member explains:
1. What has been accomplished since the last meeting?
2. What will be done before the next meeting?
3. What obstacles are in the way?
There may be brief clarifying questions and answers, but there is no discussion of any
of these topics during the Daily Scrum. However, many teams meet right after the Daily
Scrum to work on any issues that have come up.
Only the Scrum Team members, including ScrumMaster and Product Owner, speak
during this meeting. Other interested parties can come and listen in.
The Scrum Master ensures that the Development Team has the meeting, but the
Development Team is responsible for conducting the Daily Scrum. The Scrum Master
teaches the Development Team to keep the Daily Scrum within the 15-minute timebox.
Note:
The Daily Scrum is not a report to management, nor to the Product Owner, nor to the
ScrumMaster. It is a communication meeting within the Development Team, to ensure
that they are all on the same page.
Good Practices:
Inputs
1. Increment of Potentially
Shippable Product
2. Product Backlog
3. Metrics (optional)
1.
2.
3.
4.
5.
Attendees
Product Owner
Scrum Master
Development Team
Stakeholders
Other people (Optional)
Outputs
1. Revised Product Backlog that
defines the probable Product Backlog
items for the next Sprint
2. Updated Release Plan (optional)
Rules:
The Product Owner identifies what has been Done and what has not been Done
The Development Team discusses what went well during the Sprint, what problems
it ran into, and how those problems were solved
The Development Team demonstrates the work that it has Done and answers
questions about the Increment
The Product Owner discusses the Product Backlog as it stands. He or she projects
likely completion dates based on progress to date. Release Plan is often updated
during Sprint Review (optional).
This is an informal meeting, and the presentation of the Increment is intended to elicit
feedback and foster collaboration.
Good Practices:
Inspect how the last Sprint went with regards to people, relationships, process, and
tools
Identify and order the major items that went well and potential improvements
Create a plan for implementing improvements to the way the Scrum Team does its work
The Sprint Retrospective is restricted to the members of the Scrum Teamthat is the
Product Owner, Development Team and Scrum Master. Outsiders, including managers at
every level in the organization are strictly excluded unless specifically invited by the team.
When
After the Sprint
Review and
prior to the next
Sprint Planning
Meeting
Duration
3 hour time-boxed (Scrum
Guide) 4 hour time-boxed
(Scrum Alliance), meeting
for one-month Sprints.
Proportionately less time is
allocated for shorter Sprints.
Inputs
1. Sprint Data
2. Definition of Done
3. Metrics
Attendees
1. Product Owner
2. Scrum Master
3. Development Team
Outsiders strictly excluded
Outputs
1. Identified improvements
Rules:
The Scrum Master encourages the Scrum Team to improve, within the Scrum process
framework, its development process and practices to make it more effective and
enjoyable for the next Sprint.
The Scrum Team plans ways to increase product quality by adapting the Definition of
Done as appropriate.
By the end of the Sprint Retrospective, the Scrum Team should have identified
improvements that it will implement in the next Sprint. Implementing these
improvements in the next Sprint is the adaptation to the inspection of the Scrum Team
itself.
Good Practices:
Duration
10% of the Capacity of the
Development Team
Inputs
1. Product Backlog
Attendees
1. Product Owner
2. Scrum Master
(Optional)
3. Development Team
Outputs
1. Groomed (refined) Backlog
Rules:
Good Practices:
1.3 Artifacts
Scrum includes three essential artifacts:
1. The Product Backlog
2. The Sprint Backlog
3. The Product Increment.
The Team can also have optional artifacts (not core part of Scrum):
4. Burndown Chart
5. Impediment Backlog
In addition to these artifacts, Scrum requires transparency within the team and with the
stakeholders. As such, the Scrum Team produces visible displays of plans and progress.
Structure:
The Product Backlog lists all features, functions, requirements, enhancements, and fixes
that constitute the changes to be made to the product in future releases. Product Backlog
items have the attributes of a description, order, and estimate.
Good Practices:
The Product Backlog is often ordered by value, risk, priority, and necessity.
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.
When elements of the plan are deemed unnecessary, they are removed.
Only the Development Team can change its Sprint Backlog during a Sprint.
At any point in time in a Sprint, the total work remaining in the Sprint Backlog items
can be summed. The Development Team tracks this total work remaining at least for
every Daily Scrum. The Development Team tracks these sums daily and projects the
likelihood of achieving the Sprint Goal.
Scrum does not consider the time spent working on Sprint Backlog Items. The work
remaining and date are the only variables of interest.
Structure:
The Sprint Backlog is the set of Product Backlog items selected for the Sprint plus a plan
for delivering the product Increment and realizing the Sprint Goal.
Good Practices:
1.3.3 Increment
Description:
The Increment is the sum of all the Product Backlog items completed during a Sprint and all
previous Sprints. At the end of a Sprint, the new Increment must be Done, which means it
must be in useable condition and meet the Scrum Teams Definition of Done. It must be in
useable condition regardless of whether the Product Owner decides to actually release it.
Owned By:
The Product Owner
Characteristics:
The new Increment must be Done, which means it must be in useable condition and
meet the Scrum Teams Definition of Done.
It must be in useable condition regardless of whether the Product Owner decides to
actually release it.
Structure:
The Increment is the sum of all the Product Backlog items completed during a Sprint and all
previous Sprints.
Good Practices:
Characteristics:
Structure:
Good Practices:
Some teams like to burn down their sprint in story points. The rationale behind this is:
Characteristics:
Structure:
Good Practices:
Owned By:
Characteristics:
Structure:
Good Practices:
A good ScrumMaster will try to remove impediments within 24 hours of them being
identified.
Structure:
Good Practices:
Explanation: The product owner is not required to be at the daily scrum. Only The
Development Team is required to. The Scrum Master must ensure The Development Team
attends the Daily Scrum.