3. Definition of Scrum
• Scrum (n): A framework within which people can address complex
adaptive problems, while productively and creatively delivering
products of the highest possible value.
• Scrum is not a process, technique, or definitive method. Rather, it is a
framework within which you can employ various processes and
techniques.
• The Scrum framework consists of Scrum Teams and their associated
roles, events, artifacts.
4. 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.
• Three pillars build every implementation of empirical process control:
transparency, inspection, and adaptation
5. Transparency
• Process must be visible to those responsible for the outcome.
• Aspects be defined by a common standard: common definition of
Done
6. Inspection
• Scrum users must frequently inspect Scrum artifacts and progress
toward a Sprint Goal to detect undesirable variances
• Users inspection should not be so frequent that inspection gets it the
way of the work
7. Adaptation
• An adjustment must be made as soon as possible to minimize further
deviation.
• Scrum prescribes four formal events for inspection and adaptation:
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
9. Scrum Team
• The Scrum Team consists of:
• Product Owner,
• Scrum Master.
• Development Team: Scrum Teams are self-organizing and cross-
functional.
10. The Product Owner (together with Product Manager)
• The Product Owner is responsible for maximizing the value of the
product resulting from work of the Development Team.
• The Product Owner is the sole person responsible for managing the
Product Backlog. Product Backlog management includes:
• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
11. The Development Team
• The Development Team consists of professionals who do the work of
delivering a potentially releasable Increment of “Done” product at the end
of each Sprint.
• Development Teams are cross-functional, with all the skills as a team
necessary to create a product Increment;
• Scrum recognizes no sub-teams in the Development Team, regardless of
domains that need to be addressed like testing, architecture, operations, or
business analysis;
• Size: 3-9 members
12. The Scrum Master
• The Scrum Master is responsible for promoting and supporting Scrum as
defined in the Scrum Guide. Scrum Masters do this by helping everyone
understand Scrum theory, practices, rules, and values:
• SCRUM MASTER ->PO:
• Ensuring that goals, scope, and product domain are understood by everyone on the
Scrum Team as well as possible;
• Facilitating Scrum events as requested or needed.
• Understanding product planning in an empirical environment
• Finding techniques for effective Product Backlog management
• SCRUM MASTER ->DT:
• Removing impediments to the Development Team’s progress;
• Facilitating Scrum events as requested or needed
• Helping the Development Team to create high-value products
15. Scrum Events
• Each event in Scrum is a formal opportunity to inspect and adapt
something
• Failure to include any of these events results in reduced transparency
and is a lost opportunity to inspect and adapt.
16. The Sprint (2 weeks)
• The heart of Scrum is a Sprint, a time-box of 2 weeks during which a
“Done”, useable, and potentially releasable product Increment is
created.
• During the Sprint:
• Each item (story) in the Sprint Backlog should normally be developed (completed) in a
single Sprint as this is much easier to manage.
• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease;
• Scope may be clarified and re-negotiated between the Product Owner and Development
Team.
17. Sprint Planning (4 hours)
• Sprint Planning is time-boxed to a maximum of 4 hours for a 2
weeks Sprint.
• Define the Sprint Goal
• Define WHAT can be delivered in the Increment resulting from the
upcoming Sprint
• Define HOW will the work needed to deliver the Increment be
achieved
18. Sprint Planning (WHAT)
• The Product Owner has already ranked and ordered the Product Backlog
based on the value of the items
• Development Team should estimate the capacity of work it can deliver in a
single Sprint .
• The Product Owner also ensures that the items (stories) are easy to
understand
• The Development Team then selects an appropriate number of items from the
top of the Product Backlog, and puts them in the Sprint Backlog, to deliver in
the current Sprint
• Scrum Team should craft a Sprint Goal, which is an objective that should be
met within the Sprint through the implementation of the Product Backlog. The
Scrum Goal provides guidance to the Development Team on why it is building
the Increment.
19. Sprint Planning (WHEN)
• When the items to deliver are selected and the Sprint Goal is agreed, it is time
to plan how they will turn the items into a “Done” product Increment
• A detailed plan is a breakdown of a Product Backlog item into detailed tasks
needed to be done in order to create the item. Each items must have:
• Estimates,
• Dependencies.
• This planning is not necessarily completed in this meeting; having a detailed
plan for the first few days is enough. The Development Team can prepare
detailed plans for the rest of the work later on.
22. Daily SCRUM (15 mins)
• Development Team inspects the work since the last meeting, and
synchronize their work and plan for the next 24 hours
• Development Team should assess progress towards the Sprint
Goal:
• What has been accomplished since the last meeting?
• What will be done before the next meeting?
• What obstacles are in the way?
• The Development Team or team members often meet immediately
after the Daily Scrum for detailed discussions, or to adapt, or
replan, the rest of the Sprint’s work.
23. Sprint Review (2 hours)
• Scrum Team and other stakeholders gather and hold a meeting to
present and inspect the “Done” items.
• The Development Team does not present an item, unless it is 100%
complete based on the agreed definition of “Done”.
• Finally, the whole Scrum Team collaborates on revising the Product
Backlog for the next Sprint, based on the output of the Sprint and the
feedback received from the customer
24. Sprint Retrospective (1,5 hours)
• Sprint Retrospective is aimed at process improvement (learning lessons)
• It inspects the Sprint, with regards to:
• people,
• relationships,
• processes,
• and tools.
• Identify and order the major items that went well and potential
improvements
• Create a plan for implementing improvements.
25. Backlog Refining (grooming) (on-going, up to 10% team capacity)
• It is the act of reviewing and revising Product (not Sprint) Backlog items:
• adding detail,
• estimates,
• order them.
Task Accountability
Adding detail PO,PM,Development Team, SM
Estimates Development Team
Order them Product Owner
27. Scrum Artifact
• Scrum artifacts are designed to increase transparency of information related to the
delivery of the project, and provide opportunities for inspection and adaptation:
• Product Backlog: An ordered list of everything (aka stories) that might be needed in the final
product
• Sprint Backlog: Selected items (stories) from the Product Backlog to be delivered through a
Sprint, along with the Sprint Goal and plans for delivering the items and realizing the Sprint Goal
• Increment: The set of all the Product Backlog items completed up to the end of a certain Sprint
• Definition of “Done”: The shared understanding of what it means for a piece of work to be
considered complete
• Monitoring Progress towards a Goal: The performance measurement and forecast for the whole
project (product burn-down chart)
• Monitoring Sprint Progress: The performance measurement and forecasts for a single Sprint
(sprint burn-down chart)
30. NO SCRUM
• Stories lasting several SPRINTS -> no shippable releasable increment
• NO Shared Definition of Done -> no shippable releasable increment
• NO task break down for the SPRINT Items -> no transparency, no plan
• SKIPPING Scrum Events -> less transparency, inspect and adaptation
• Architect Team, Developer Team, QA Team -> ONLY Development team
• NO Cross- functional DT -> too many dependencies, hard to plan
• NO Self-organizing DT -> Requires a PM, not included in SCRUM
