Scrum Personal Guide
Scrum Personal Guide
process).
Iterative and incremental knowledge transfer. Used for products, services, management
parent organization.
Empirical process control or empiricism: framework within which people can address
complex adaptive problems while productivity and creativity delivering products and
services of the highest possible value
Scrum Master:
• Remove impediments
• Promoting and supporting
• Helping everyone to understand (theory, practices, rules and values)
• Helps those in and outside Scrum Team
• Helps everyone change interactions to maximize the value created by Scrum Team
Product Owner:
• Say “no!” positively
• Contact between team and stakeholders
• Product Backlog, sorted by priority (thanks to stakeholders)
o Is never complete
o Is dynamic
o As long as product exists, it’s Product Backlog exists
o Clearly expressing Product Backlog items
o Ordering to best achieve goals and missions
o Optimizing value of work of dev. Team
o Ensuring visible, transparent and clear to all and shows what scrum team will
work on next
o Ensuring dev. Team understands items in product backlog to level needed
• Respect decision and visible decisions
• Sprint Review: total work remaining summed
Dev. Team:
• Delivers increment to Product Owner, who presents it to the stakeholders at end of
Sprint.
• Done increment required at end of Sprint
• Structured and empowered by organization to organize and manage their own work
• Only dev. Team create increment
• Characteristics:
o Self-organizing (no one tells dev team how to turn Product Backlog into
increments op potentially releasable functionality)
o Cross functional, all skills needed to create product increment
o Scrum recognizes no titles, regardless of work being performed by the person
o Scrum recognizes no sub-teams, regardless of domains (like testing,
architecture, operations or business analysis)
o Accountability belongs to complete team, even when members have
specialized skills
5 VALUES 3 PILLARS
Courage Transparency
Focus Adaption
Commitment Inspection
Respect
Openness
INVEST
Independent Negotiable Valuable Estimable Small Testable
The Sprint:
• Potentially releasable product Increment
• One (1) month or less
• During:
o No changes are made that would endanger the Sprint Goal
o Quality goals don’t decrease
o Scope may be clarified and re-negotiated between Product Owner and
Development Team as more is learned
o Each Sprint may be considered as a project with no more than 1 month
horizon
o Goal, design, flexible plan à increment
o
Sprint planning:
• Start of Sprint
• Velocity / team capacity
• Sprint Goal
o Guidance on why increment is build
• “Done” product increment à What will the end product look like?
o Ensures artifact transparency
o Guides dev. Team in knowing how many Product Backlog items it can handle
o Asses when the work is complete on the product increment
• User Story
• Dev. Team chooses User Stories from Product Backlog, added to Sprint Backlog + a
plan to deliver
• Only choose User Stories, not who fulfills it
• Dev. Team explain should be able to explain to Scrum Master and Product Owner
how it intends to work as self-organizing team to accomplish Sprint Goal
• Who must attend:
o Scrum Master à Keeps overview
o Dev. Team
o Product Owner à Takes decisions
o Invite the world, for technical or domain advice à transparency
Daily Scrum:
• Has no prescribed structure
• 3 questions:
o What were you working on?
o What will you work on?
o What were the impediments?
• Who must attend:
o Dev. Team
o Not invite the world
o Same place, same time à Reduce complexity
o If others present, they can’t disrupt dev team
• After meeting immediately meet for detailed discussion, or to adapt re-plan rest of
the Sprint’s work
• Improve communication
• Eliminate other meetings
• Identify impediments
Sprint Review:
• Who must attend:
o Product Owner
o Dev. Team
o Invite the world
• Demo
• Feedback
• Take a look at next Sprint
• Product Owner invites stakeholder to learn the current state of the market place
influences and what’s the most valuable thing to do next
• Product Owner shares the current state of the Product Backlog, which, combined
with the inspection of the increment, which leads to an updated product backlog
Retrospective:
• Who must attend:
o Product Owner
o Scrum Master
o Dev. Team
o Not invite the world à Safe environment
• Inspect how last Sprint went, with regards to people, relationship, 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
• Definition of Done can change if appropriate
Functional:
• Epics
• User Stories
Non-functional:
• Technical (conditions)
• Bugs
• Spikes (research & learning)
o More research necessary, weekly meeting (waterfall method would call this
analysis phase).
Nexus framework:
• Multiple Scrum Teams, same product (3-9 scrum teams on 1 product)
o Doesn’t require same Sprint length/duration (not aligned)
• 1 Product Backlog
• 1 Product Owner
• Every team own Sprint Backlog
• Continues integration
• Prevent dependencies
What are the main purposes of the product backlog refinement at scale?
- Identifying dependencies across teams
- Forecasting which team will deliver which Product backlog items
Cancelled Sprint:
• Any “done” Product Backlog items are reviewed
• If part of work is releasable, Product Owner typically accepts it
• All incomplete Product Backlog items are re-estimated and puck back on the Product
Backlog
• Often are traumatic
• Consume resources
• Very uncommen