Scrum Cheat Sheets – Scrum Team & Scrum Artifacts

Self-organization – Teams find their own way, autonomously choose how best to Artifacts represent work or value to provide transparency and opportunities for inspection and adaptation
accomplish the work and make local decisions - Designed to maximize transparency of key information so that everybody has the same understanding of the artifact
Cross-functionality - Having all competencies needed to accomplish the work
without depending on others The Product Backlog is the single source of requirements Sprint Backlog = Product Backlog Items + Plan A usable, releasable, “Done” Product
- Ordered list of everything that is known to be needed in the - Forecast about what functionality will be in the next Increment is a step towards a vision or goal
Definition of “Done” (DoD)
product (functions, features, requirements, enhancements, fixes) Increment and about the work needed to deliver it - Sum of all Items completed during a Sprint and
- Defines all the work that needs to be done on an Item to turn it into a part of the
- Never complete and a living artifact which evolves as the product - Plan with enough detail that changes in progress the value of the Increments of all previous
Increment
and its environment (business, market, technology) evolves can be understood in the Daily Scrum Sprints
- Common understanding of “Done” for an Increment or an Item to create
- Dynamic and constantly changes to identify what the product - Crafted during the Sprint Planning - At the end of a Sprint, the new Increment
transparency
needs to be appropriate, competitive and useful - At least one high priority improvement identified in must be “Done” (usable and meet the Scrum
- Guides the Development Team in knowing how many Items it can select during a
- One Product Backlog for one product the previous Sprint Retrospective is included Team’s Definition of “Done“)
Sprint Planning
- Highly visible, real-time picture of the work/tasks - Body of inspectable, done work that supports
- Companywide convention is present: All Scrum Teams must follow it as a minimum A Product Backlog Item is more detailed the higher the order
that the Development Team plans to accomplish empiricism at the end of the Sprint
- If multiple Scrum Teams are working on the product, the Development Teams of all - Attributes: Description, Order, Estimate, Value, Grouping Attribute,
- Belongs to the Development Team as whole not to - Work of the Development Team
the Scrum Teams must mutually define the DoD. This DoD must be compatible, Test Description
individual team members - Each Increment is additive to all prior
and capable of creating ONE integrated Increment. - Items that can be “Done” within one Sprint are “Ready” for
- Quality methods and non-functional requirements are included in the DoD - Selected Items do not change, work/tasks do Increments and thoroughly tested ensuring
selection in a Sprint Planning
- We keep improving the DoD when we mature change frequently that all Increments work together
- Non-technical and independent
- Each Team needs a separate Sprint Backlog

The Product Owner is responsible for change management and - Clearly expressing Items (Content) - Responsible for optimizing/maximizing the
managing the Product Backlog (She “owns” it). - Order/Prioritize Items by value (up to the Product Owner) to best value
- One person à One Product Owner for one Product/Project achieve goals and missions - Decides if the Increment is released (It is not
- Entire organization must respect his decisions - Decisions are visible in the content and ordering required to release all Increments)
- Stays accountable but may outsource the work - Ensure visibility, transparency and clarity to all, so that it shows
- Has the authority to cancel a Sprint as the only one what the Scrum Team will work on next
- Must be addressed by those wanting to change an Items priority - May help to understand and select trade-offs
- Proven itself to be increasingly effective for all the earlier stated uses and any complex work

- Accountable for the Total Cost of Ownership (All investments

required to conceive, develop, operate and maintain the product) Ensuring the Development Team understands Items to the level
- Deliver products iteratively and incrementally, maximizing opportunities for feedback

- Measure success by customer satisfaction or KPIs through frequent needed If the work turns out to be different than
releases, NOT by increased velocity or production cost During the Product Backlog Refinement Items are expected the scope of the Sprint Backlog is
reviewed and revised negotiated within the Sprint
The Development Team recognizes neither titles nor sub-teams - Act of adding detail, estimates and order to Items - Professionals who do the work of delivering at
- Structured and empowered by the organization to organize and - Ongoing process of collaboration - Modifies the Sprint Backlog throughout the Sprint the end of each Sprint
manage their own work - Items are reviewed and revised - Emergence occurs as the Development Team works - Only members of the Development Team
- Resulting synergy optimizes overall efficiency and effectiveness - Consumes ≤ 10% of the capacity of the Development Team through the plan and learns more about the create it
- Accountability to the team as a whole - Items that will occupy the Development Team for the upcoming work/tasks needed to achieve the Sprint Goal - Keep the Sprint Goal in mind
- More developers ≠ higher productivity - Small enough to remain - Only the Development Team can change its Sprint - In order to satisfy the Sprint Goal, it
- Decides how and when Product Backlog Refinement is done

Sprint are refined so that they can reasonably be “Done” within

A (Scrum) Team is self-organized and cross-functional

nimble, large enough to complete significant work within a Sprint the Sprint Backlog during a Sprint. implements functionality and technology
- Recommended to have dedicated developers, but not mandatory - Should be made in one or two preceding Sprints or during the - As new work/tasks are required, the Development
- If Development Teams change, it shouldn't be during the Sprint Sprint, if this did not happen Team adds them to the Sprint Backlog.
- Unnecessary Items are removed.
¯ Interaction
­ Coordination - No one can force the Development Team to work from a different - The total work remaining can always be summed
¯ Productivity gains
< 3-9 < - Too much complexity for an set of requirements. - Work/Tasks are assigned to Developers (by
- Skill constraints, unable
empirical process - Responsible for all estimates themselves), but all stay accountable
to deliver Increment

The Scrum Master is a servant-leader and a management role - Find techniques for effective Product Backlog management - Lead and coach in Scrum adoption - Coach in self-organization and cross-
for processes - Understand product planning in an empirical environment - Plan Scrum implementations functionality
- Responsible to promote and support Scrum as defined - Ensure knowledge about Item arrangement to optimize value - Help employees and stakeholders understand and - Coach in organizational environments in which
- Help understand Agility, Scrum theory, practices, rules, values enact Scrum as well as empirical product Scrum is not yet fully adopted or understood
- Facilitate Scrum events as requested/needed development - Help to create high-value products
- Help the Team to understand goals, scope and product domain - Cause change improving productivity of the Team - Remove impediments to their progress
- Help the Team understand the need for clear and concise Items - Work with other Scrum Masters the effectiveness of (sometimes supported by the Senior
- Works with all participants to understand if artifacts are transparent the application of Scrum in the organization Management or the Development Team)
(inspecting artifacts, sensing patterns, listening to what is being said, - Help others understand which interactions with
differences between expected and real results) the Team are helpful, which aren’t and to change
- Increase transparency of the artifacts working with participants these

Service of the Scrum Master to the … Product Owner Organization Development Team

09/2020 www.fellow.coach © fellowork GmbH 1

 Scrum Cheat Sheets – Scrum Team & Scrum Events
Events are a formal opportunity to inspect and adapt (feedback loops), designed to enable critical transparency
- Create regularity and minimize the need for meetings not described in Scrum
- Events may end whenever the purpose is achieved

During the Sprint Planning the Sprint Goal is crafted The Daily Scrum is an internal meeting for the The Sprint Review is an informal meeting, not a status During the Sprint Retrospective major Items that went
[≤ 8 h] at the beginning of the Sprint Development Team meeting well, and potential improvements are identified and
? What can be delivered in the Increment resulting from the [≤ 15 min] every day same time and place [≤ 4 h] held at the end of the Sprint ordered
next Sprint? - Optimize collaboration, performance and probability - Inspect the Increment and review the feasibility of the project [≤ 3 h] after Sprint Review and prior to the next Sprint
? How will the work needed to deliver the Increment be to meet the Sprint Goal by inspecting the work since - Key stakeholders are invited Planning
achieved? the last Daily Scrum and forecasting upcoming work Latest “Done” Increment, Product Backlog - Inspect how the last Sprint went with regards to people,
Product Backlog, Latest Increment, Capacity of Development - Improve communication, eliminate other meetings, Revised (and adjusted) Product Backlog defining the relationships, process and tools
Team, Past performance of Development Team identify impediments, promote quick decision-making, probable Product Backlog Items for the next Sprint to meet - Plan for implementing improvements to the way of working
Sprint Goal, Sprint Backlog, Commitment and improve knowledge new opportunities of the Scrum Team

- Collaborate on understanding the work - Collaborate on what was done in the Sprint - Inspect itself, identify improvements and create a plan for
- Plan the work to be performed - Collaborate on what to do next, so that it provides valuable improvements to be enhanced during the next Sprint
- Creates the Sprint Goal input to subsequent Sprint Planning and to optimize value - Plan ways to increase product quality by improving work
Scrum Team

- Review how the market/potential use of the product might have processes of adapting the definition of “Done”, if appropriate
changed and not in conflict with product or organizational standards
- Review timeline, budget, capabilities and market for the next
anticipated releases of functionality or capability of the product

- Discuss the objective/target that the Sprint should achieve, but - NOT required/allowed to attend - Invite key stakeholders - Mandatory to be present
does not prepare the Sprint Goal - Explain what Items have been “Done” and what not
Product Owner

- Discuss the Items that would achieve the Sprint Goal - Discuss the Product Backlog as it stands
- Help to clarify selected Items and make trade-offs - Project likely target/delivery dates based on progress to date
- Tracks the total work remaining and compares it with work
remaining of previous Sprints to assess progress toward
Re-negotiation of selected Items if Development Team completing projected work by the desired time for the goal
determines it has too much or too little work (Project performance measurement)

- Forecast the functionality that will be developed - Set the structure of the meeting and conduct the event - Discuss what went well during the Sprint, what problems the - Mandatory to be present
- Crafts Sprint Backlog by selecting Items from the Product - Plan the work for the next 24 h team ran into, and how those problems were solved
Backlog - Inspect progress towards the Sprint Goal and how - Demonstrates the Increment and answers questions (elicit
- Decide how to build the functionality into a “Done” Increment progress trends towards completing the work in the feedback and foster collaboration)
- Design the system and the work/tasks needed to convert the Sprint Backlog (Sprint performance measurement)
Development Team

Product Backlog into a working Increment - Understand how it intends to work together as a self-
- Enough work is planned to forecast what the Development organizing team to accomplish the Sprint Goal
Team believes it can do in the upcoming Sprint
- Work planned for the first days of the Sprint is decomposed ? What did I do yesterday to meet the Sprint Goal?
- May invite others to attend to provide technical/domain advice ? What will I do today to help to meet the Sprint Goal?
- Able to explain how to work as a self-organizing team to ? Do I see any impediment that prevents me/us from
accomplish the Sprint Goal meeting the Sprint Goal?

- NOT required/allowed to attend - Ensure positivity and productivity and encourage to improve
- Ensure that others don not disrupt the meeting if - Participate as a peer team member from the accountability
Master

present over the Scrum framework

Scrum

Ensure that the events take place, the attendants understand the purpose and teach the Scrum Team to keep them within the time-box

The Sprint is a container for all other Scrum Events - Quality Goals do not decrease The Sprint Goal is an objective set for the Sprint that can be met through the implementation of
[≤ 1 month] with consistent/fixed duration throughout the development - Scope may be clarified and re-negotiated Product Backlog Items
effort - Limit risk to one month of cost - Provides guidance to the Development Team on why building the Increment
- Too long: ­ complexity, risk & definition of what is being built may change - All Sprints are the same: No Sprint 0, no integration Sprint etc. - Gives some flexibility to the Development Team regarding the functionality implemented within the Sprint
- Usable, potentially releasable and “Done” Product Increment is created - Short enough to keep business risks acceptable to the Product - The selected Items deliver one coherent function which can be the Sprint Goal
- New Sprint starts immediately after the conclusion of the previous Sprint Owner and to be able to synchronize the development work with - Can be any other coherence causing the Development Team to work together rather than on separate
- No changes are made that would endanger the Sprint Goal other business events initiatives

Sprint Cancellation can only be done by the Product Owner

? If it no longer makes sense given the circumstances ? Market or technology conditions change - “Done” Items are reviewed - Traumatic to the Scrum Team
? Sprint Goal obsolete - Incomplete Items go back to the Product Backlog re-estimated - Consumes Resources

09/2020 www.fellow.coach © fellowork GmbH 2