Zusammenfassung Scrum Guide

Alle verwendeten Bilder sind Eigentum von Scrum.org bzw. anderen Erstellern. Die Quellen sind unten verlinkt!

Übersicht


Der Scrum Guide lässt sich in folgende Kapitel aufteilen.



Klick auf das jeweilige Thema um mehr zu erfahren!


Die folgenden Inhalte sind auf Englisch, da auch die Tests auf Englisch sind.


Viel Spaß!


Tobias Fleming

Scrum Values

These values help the Scrum Team working together, the actions they do should support those values not harm them.

For better memorization: "FROCC"


  • Courage to do the right thing and to work on problems, instead of waiting long times for approvements.
  • Focus on the work of the Sprint and their goals.
  • Commitment to support the team and working towards the teams shared goal not your own goals.
  • Respect between the Team Members, their acountabilities and indepedence.
  • Openness for learning new things and new strategies, but also about the current progress, team healthiness and when help is needed.

Scrum Theory (Empiricism)

Scrum is based on empiricism and lean thinking, which means that knew things are learned from experience. Lean thinking is about finding and eliminating wasteful processes in an environment in order to concentrate on the key aspects.

Short: Learn from experience, make decisions based of your previous experience and focus on the main points.


  • Trust is the foundation of every work environment, without trust between all participants the following aspects are irrelevant.
  • Transparency is created through a high level of courage and trust within a team. It is important to have clear communication about the progress towards the team goals and team status. Without Transparency Inspection becomes misleading and a waste of time!
  • Inspection helps the team to find ways to improve and inspect their current doings. The Events are designed to give room for improvements and to repeat that process over and over again to improve over time!
  • Adaption is important after misleading behaviors or processes are identified, to make them as efficient as possible.

Scrum Roles

Scrum consists of three roles, but in the Exams there are also question about the whole Scrum Team. For every part the scrum guide give some facts to know for the exam and understand the role and their accountabilities.

In generel: Every Team has ONE Scrum Master, ONE Product Owner and some Developers. For a scaled environment: For ONE product there is ONE product owner, ONE product backlog and ONE product goal.


  • The Product Owner
    • One person not a committee.
    • Ensures the product backlog is understood, transparent and accessible.
    • Accountable for maximizing the value of the product, for effective Product Backlog Management, for developing and communicating the Product Goal and crafting and communicating the Items of the Product Backlog; Short: Product Backlog Manager and Value Optimizer.
  • The Developers
    • Committed to create an valuable releaseable Increment each Sprint.
    • Creating the Sprint Backlog and Sprint Goal together with the Product Owner and ensuring quality by commiting to the Definition of Done; Checking and adapting the plan towards the Sprint Goal during Daily Scrum.
  • The Scrum Master
    • Accountable for establishing the scrum framework in the Scrum Team and Organisation.
    • Impediment Remover and Facilitator for the Scrum events.
    • Ensures that all Events are kept in their timebox and have a positive impact on the team and product.
    • Helps the product owner and developers during their work regarding techniques, tools and theory regarding scrum.
  • The Scrum Team
    • Focused on the Product Goal; Empowered by organization to manage own work; Cross-functional and self-managing; Have all skills needed to create value each Sprint; No sub-teams or hierarchies; Responsible for all product-related activities;
    • Creating a valuable and useful Increment every Sprint.
    • Consists of 10 or fewer people.

Scrum Events

  • Sprint Review
    • Discuss the Increment with the team and stakeholders to gain feedback for upcoming Sprints.
    • All Scrum Team members, stakeholders and others to gain feedback from are part of it.
    • The timebox is 4 hours or less for Sprints shorter one month.
    • Inspect what is the result of the Sprint; Adjust the Product Backlog when needed by the feedback; Discuss next steps and ideas;
  • Scrum Retrospective
    • Definition of Done, interactions, processes and tools get inspected to improve over time.
    • All Scrum Team members are part of it and Product Owner and Scrum Master are part if it as team members.
    • The timebox is 3 hours or less for Sprints shorter one month.
    • Improvements are applied as fast as possible and could be added as items on the next Sprint Backlog or part of the Definition of Done;Ends the current Sprint;

The Sprint is the heart of scrum.

During the Sprint the backlog is refined when needed, the scope may be renegotiated with the product owner as more is learned (cone of uncertainty) and no changes are made which could endanger achieving the Sprint Goal.

Every Scrum Event listed contains the purpose, who takes part, the time box and lastly the topics discussed.


  • Sprint Planning
    • Starts the Sprint by planning the work to be done during the Sprint.
    • All Scrum Team members are part of it.
    • The timebox is 8 hours or less for Sprints shorter one month.
    • Why is this Sprint valuable? What can be Done this Sprint? How will the chosen work get done?
  • Daily Scrum
    • Check progress towards the Sprint Goal, adjust Sprint Backlog when needed and identify impediments.
    • This is an Event for the Developers of the Scrum Team.
    • The timebox is fixed to 15 minutes.
    • Takes place at the same location and time to reduce complexity; Meeting structure is freely selectable as long as purpose is fulfilled; When the Product Owner or Scrum Master are working on items, they participate as a Developer;

Scrum Artifacts and Commitments

Every artifact has its own commitment in Scrum. Artifacts help the team to maximize transparency and their commitments exist to improve the usage of empiricism and scrum values for all participants.

Artifacts



  • Product Backlog
    • Emergent and ordered list managed by the Product Owner.
    • Single Source of Truth for the Scrum Team and can be refined during the Sprint.
  • Sprint Backlog
    • Created by and for the Developers during Sprint Planning with Input from the Product Owner to achieve the Sprint Goal.
    • Consists of the Sprint Goal (Why?), the Items for the Sprint (What?) and a plan to deliver them (How?).
  • Increment
    • The result of a every Sprint, created by the Scrum Team conform with the Definition of Done.
    • Part of the progress towards the Product Goal and addable to the Increments of previous Sprints.

Commitments



  • Product Goal
    • Describes the future state of the product and is the long term objective of the Scrum Team to plan against.
    • Useful for planning and boosts the teams motivation.
  • Sprint Goal
    • Single objective for the Sprint, part of the product goal and commitment by the Developers.
    • Creates transparency, commitment, motivation and team feeling for the Scrum Team.
  • Definition of Done
    • Formal description of an Increment when quality standards are considered as "done", so when a Product Backlog Item is considered as done an Increment is born.
    • Creates a shared understanding about the word "done" to enhance transparency.

Extra Content

This is a list of expressions frequently used in the context of scrum and the scrum.org exams.

  • Timebox
    • Target-based time management strategy.
    • The activity should take place during the given time, to help the team focus on the main aspects.
  • Product Backlog Refinement
    • Defining Product Backlog Items more clearly to ensure transparency.
    • Ongoing activity to add order, size or estimation to an Item.
    • Can be done during the Sprint whenever needed.
  • "Ready"
    • In praxis some teams use a Definition of Ready, which is a state a product backlog item must achieve, before it can be selected for a sprint during sprint planning.
    • In this context sometimes a Definition of Ready is used, which contains rules the items need to contain (ex. 3 user story or an estimation).
  • Velocity
    • Velocity is understood as the number of functionalities delivered by the team per Sprint. As an example story points delivered per Sprint, provide one type of measure for velocity.
    • Velocity should not be used to compare teams as illnesses or harder items are not recognized.
  • Technical Debt
    • Technical debt is the word for a poor implementation of code for example, when items where not integrated correctly or things like testing or refactoring where not done as mentioned in the Definition of Done.
    • When technical debt occurs the real state of the product is unclear as some items need some extra work.
    • Technical Debt can be used to improve velocity but harms long term transparency and velocity.
  • Cone of uncertainty
    • The cone of uncertainty describes the state of an project at the beginning where a lot is unknown and not predictable, but during the Sprint more and more gets clearer.
    • It is good to use for stakeholders explanations.

Links to images

Used Resources

1. Scrum Guide

2. Scrum Framework

3. Scrum Values

4. Scrum Accountabilities

5. Empiricism