Outline of Scrum Guide 2020

I created my personal notes about the new scrum guide for a while, as the guide is out since 2020 November. However I decided to summarize/outline in an article only now. However it was written in early 2021.

At its core, Scrum is a lightweight framework designed to guide individuals and teams in generating value by addressing complex problems.

Scrum has a key role called as the Scrum Master, who cultivates an environment conducive to the following iterative process during a Sprint:

  1. Product Owner’s Role: Ordering work into a backlog.
  2. Team’s Responsibility: Transforming selected work into an Increment of value during the Sprint.
  3. Joint Inspection: Team and Stakeholders collaboratively inspect results and make adjustments.

While the structure of Scrum is straightforward, each component is integral. It’s not a detailed set of instructions but rather a guiding framework for team relationships and interactions.

Scrum Theory

Scrum is built on an iterative, incremental approach with four formal events within a Sprint. The Scrum Theory hinges on key attributes:
Empiricism: Knowledge derived from experience, emphasizing observation, learning, and informed decision-making.
Lean Thinking: A focus on reducing waste and prioritizing essentials.

Scrum events are implementing the following empirical pillars:

  • Transparency – Visibility of processes and work, promoting inspiration
    low: diminish value, increase risk
    high: enables inspiration
  • Inspection – Frequent scrutiny of artifacts and agreed-upon goals, enabling adoption.
    artifacts and aggred goals must be inspected frequently
    enables adoption
    scrum events designed to provoke change
  • Adaptation – Rapid adjustments in response to process deviations or changes in product requirements
    process deviation, product result requires process or material changes, adjustments
    dificulty if people not empowered or self-managing
    Adapt fast

Scrum Values

commitment, focus, opennes, respect, courage

Scrum Team

The Scrum Team comprises a Scrum Master, a Product Owner, and developers,
forming a cohesive, cross-functional, and self-managing unit. This unit, focused on a singular objective—the Product Goal

cross-functional: all skills to create value
self-managing: internally decides what, when, and how

Small enough to remain nimble, big enough to complete significant work in a Sprint ( <10)
Smaller team communicates better and delivers better.
To large team should consider reorganize multiple focused on the same product
All accountable for creating valuable, useful increment every sprint.


Developers, committed to creating a usable increment, are accountable for various tasks, including:

  • creating plan for sprint; sprint backlog
  • instilling quality by DoD
  • adapting plan toward sprint goal
  • holding each other accountable

Product Owner

maximizes the value of product resulting the work of team accounted for:

  • developing and communicating Product Goal
  • creating, communicating backlog items
  • ordering backlog
  • ensuring backlog transparency, visibility, understanding

Can represent multiple stakeholders

Scrum Master

establishes scrum as defined. Communicates to team and organization
accountable for effectiveness by enabling practices.

  • coaching team ( self-management, cross-functionality )
  • helps focusing high value increments by keeping DoD
  • removes impediments
  • Scrum Events -> positive, productive, time-boxed
  • serves PO: Product Goal, backlog items, Product Planning, stakeholder collaboration

Scrum Events

Each Event is an opportunity to inspect and adapt
These events should minimize the need of other meetings. Hold at the same time and place


Ideas into value
Fixed length (1 month or less)
All the work necessary to achieve the Product Goal, including Sprint Planning, Daily Scrums, Sprint Review, Retrospective


  • keep Quality
  • Product Backlog is refined
  • scope may be clarified – renegotiated with PO

long vs. short sprint:
with short: less complexity, more clarity (Sprint Goal), more learning cycle, limited risk

Predictability by burn-down, burn-up, comulative flows

Sprint can be canceled by PO if the Sprint Goal becomes obsolete

Sprint Planning

Initiates the sprint by laying out thge work to be performed,
PO ensures the team collaborates on the plan by mapping the backlog items to the Product Goal
Team can invite other people for advice

Planning addresses:

  • Why sprint is valuable?
    PO proposes how to increase value of the product, then the team defines the Sprint Goal
  • What can be done in a Sprint?
    Through discussion with PO, devs select Backlog items and may refine them to increase understanding and confidence
    Challenges: How much items? Know past performance, upcoming capacity, DoD to forecast
  • How will the chosen work get done?
    For each item devs plan the work to create the Increment that meets DoD. This is often done by decomposing items into smaller work items
Sprint Backlog

Sprint Goal and Product Backlog items selected for Sprint plus their delivery plan
Planning is time-boxed for 1 month Sprint is max. 8 hours.

Daily scrum

Purpose to inspect progress towards the Sprint Goal, adjust in the upcoming work
15 min event for devs, held the same time, same place every working day
PO and SM participates if they actively working on items
Structure and techniques are open as long it focuses on progress toward the Sprint Goal and produces actionable plan
Improves communication, identifies impediments, promotes quick decision-making, eliminates need of other meetings

Sprint Review

Purpose to inspect outcome of Sprint and determine adaptations.
Team presents the work to stakeholders and progress toward Sprint Goal is discussed
based on accomplishment and environment changes attendees collaborate on what to do next
This is a working session, should avoid limiting to presentation
Time-box: 4 hours on monthly sprint

Sprint Retrospective

Purpose to plan ways to increase quality and effectiveness
Inspect last Sprint worth regards to individuals, interactions, processes, tools and DoD
Discuss what went well, that problems occurred, how those were solved
Identify and address improvements
Retrospective concludes a Sprint
time-boxed: 3 hours for a month sprint

Scrum Artifacts

Represents work or value, designed for maximize transparency of key information for

  • Product Backlog -> Product Goal
  • Sprint Backlog -> Sprint Goal
  • Increment -> Definition of Done
Product Backlog

Emergent, ordered list of improvements of the product
Refined items going into the Sprint Planning selection
Refinement – until an item fits into one sprint and satisfies Definition of Ready – is the breakdown process to split and clarify items to be more precise
Devs responsible for sizing
PO influences devs by helping understanding

Commitment: Product Goal

describes a future state of product as a target to plan against
Product is a vehicle to deliver value. It has clear boundary, known stakeholders, well-defined users/costumers.
Product could be a service. Physical product or more abstract as well
It’s the long term goal of the Team

Sprint Backlog

composed of:

  • (why) Sprint Goal
  • (what) set of Backlog items selected
  • ( how) actionable plan to deliver the Increment

Highly visible picture of work that devs plan to accomplish to achieve Sprint Goal

Commitment: Sprint Goal

single objective for the Sprint
creates coherence and focus encouraging the team to work together
created during Sprint Planning event
If work turns to be different devs and PO collaborate on the scope of backlog


Concrete stepping stone forward Product Goal
Increments are additive to prior ones and working together to provide value.
Increment must be usable
Multiple increments may be created in one sprint
They may be delivered before sprint end, Sprint Review shouldn’t gate release
work cannot be considered part of Increment unless meats DoD

Commitment: Definition of Done

Formal description of state of Increment, when it meets quality measures of the Product
as a backlog item meets DoD an Increment is born
creates transparency by shared understanding
item doesn’t meet DoD shouldn’t be released

Scrum framework is immutable. While implementing parts of it is possible, however the result won’t be Scrum.

Exists only in it’s entirety and functions well as a container for other techniques, methodologies and practices.

Correlation Identifier

Correlation identifier of requests-responses is an essential feature of microservice platforms for monitoring, reporting, debugging and diagnostics.
Allows tracing a single request inside the application flow, when it can often be dealt with by multiple downstream services.

Problem statement

The most trending direction in software development is distributing processing and systems. I nsoftware architectual system designs there are multiple service layouts: single monolithic systems, SOA distribution, and nowadays microservice level grouping of services, applications.
In case of multiple services, we should consider, even multiple running entities from one specific service.

In case of looking into the logs, we could have a harder time to track down the chain of calls and locate the specific instances, which was hit by the request, through serving a user request.

A request hits through GraphQL service, the User, Order, Payment, Shipping services on different instances

You will need to centralize the log messages from multiple services and multiple instances.
Order these log entries in timely order and then somehow group the relevant ones.
Here comes the correlation identifier in picture. It uniquely identifies the request, and generated-passed through and persisted along the log entries of the systems.

With propagated identifiers instead of various, you’ll have consistent log ids through a specific request life-cycle across every single service


You have multiple options how to generate, transport and store this identifier.

Generally you want to generate it at the first entry point and pass it down.
In the above the GraphQL proxy would serve as an entry point, which makes it easy to handle the generate and addition in one place.
In another layout I would suggest the following:
if you don’t have id, generate and add to the request
if you received an id, use and pass it along the outgoing requests

You have to define your HTTP interface and pass this data on requests. Similar options applicable non-HTTP request.

You can either extend the request/response body, (POST request, Responses with payload). However this way your model interfaces will be distorted with a non-product specific attribute.
A better option is to use a custom header parameter or cookies (Header: x-correlation-id).

What value?
The correlation Id value should be an unique identifier, so UUID is a good candidate. (while there is theoretical chance of, collision, the probability is very-very low)

Also the correlation Id could contain business level identifiers as well. This way the id will be more informative, it even adds extra query grouping ability. On simple systems it could make sense to use a basic product id. it’s simpler and smaller.
Also you can combine the above two. Using 1-2 unique identifier with a timestamp or simply generated value. UniqueId-productType-UUIDsmallHash


If we made all the decisions, we should put the identifiers into the application logs.
From that on, you only have to use aggregated log solutions to gain on the the correlation id.
Track the request along the services with simple querying.
Either with simple grep if the logs are accessible from a central place or with the use of log aggregate applications, loKi, loggy, splunk, etc.

In the second article Correlation Identifier - In Practice, I'll present examples in more detail how you can effectively generate-process the identifier, and how to add the information to the logs.


Amazon uses X-Amzn-Trace-Id https://aws.amazon.com/premiumsupport/knowledge-center/trace-elb-x-amzn-trace-id/

Spring Cloud Sleuth – uses trace-id and provide span-id s as work-units

correlation-id is used by jms systems, i.e.: ActiveMQ, RabbitMQ