My personal notes on the new Scrum Guide 2020

A new Scrum Guide was presented to the world earlier this week. I have never seen such a buzz around any of the previous releases, so I decided to take some time to read the guide while having a few espressos and writing my thoughts as I slowly digested the paragraphs.

Below are my personal views that I am sharing with you. Some views you might agree on others you may not and that’s ok.

The Scrum Guide contains the definition of Scrum. Each element of the framework serves a specific purpose that is essential to the overall value and results realized with Scrum. Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless.

Section: Purpose of the Scrum guide

My thoughts: In this new version the authors made it very clear in the beginning of the guide that not following the rules of Scrum or leaving out elements can lead to covering up problems, in the previous version there wasn’t a direct statement like this.

Scrum is built upon by the collective intelligence of the people using it. Rather than provide people with detailed instructions, the rules of Scrum guide their relationships and interactions.

Section: Scrum Definition

My thoughts: Many frameworks out there are very prescriptive and defines not only the What but the How, the Scrum authors seems to defend a view that the execution of Scrum can be done in different ways, it’s up to (intelligent) people to find out the best way to do it.

Scrum engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed

Section: Scrum Theory

My thoughts: Seems this is giving a reference for T-shaping individuals and foster knowledge to be shared across the team.

Inspection enables adaptation. Inspection without adaptation is considered pointless. Scrum events are designed to provoke change.

Section: Inspection and Adaptation

My thoughts: In the previous version of the Scrum Guide the authors use the word “Inspector” which almost made people believe that the Scrum Master or the Product Owner were the inspectors… or worse… somebody from outside the team, this caused some confusion, in this new version it makes crystal clear that the Scrum team is expected to adapt once there’s a reason to do so.

Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.

Section: Adaptation

My thoughts: Empowerment is a word that now appears two times in the new guide instead of one time. The authors probably recognize that many organizations setup Scrum Teams but these are not empowered, rather they are controlled and forced to follow certain rules and standardization requirements hindering their capacity to adapt.

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

Section: Scrum Team

My thoughts: Two new ideas here…

No sub teams as previously with the term Development team that was part of the wider Scrum Team.
Not encouraging at all, having people working in multiple things at the same time or “50% allocation” type of thing, as effective Scrum Teams are composed of focused individuals.

If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

Section: Scrum Team

My thoughts: Until this new version came out, there wasn’t any indication what would happen when Scrum Teams become very large, the authors acknowledge that this may happen and when it happens there will be only one backlog and one product owner, nothing is said about sharing the same Scrum Master - SAFe notoriously break with this principle.

The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work.

Section: Scrum Team

My thoughts: The authors puts the responsibility of dealing with stakeholders and other activities with the whole Scrum Team and not for a specific role. In reality in organizations where Scrum is not well understood, Scrum Masters are used to do the “admin” work and deal with all the obstacles.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team

Section: Daily Scrum

My thoughts: Removed the term time-boxed comparing with the previous version, what happens at the minute 16?

Were is the time-boxing Jeff and Ken?

What if the goal of the Daily is achieved in 10 minutes?

I think this is being prescriptive to the letter…

The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management

Section: Daily Scrum

My thoughts: Removed the 3 questions that made every Daily Scrum look like a punishment session and a status report to the Scrum Master.

I wonder what many poor Scrum Masters out there will be doing now…

However I do believe that for teams that transitioned to Scrum and are still not very used to this every day collaboration event, having some sort of guidance is helpful.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

Section: Sprint Retrospecive

My thoughts: The previous version of the guide implied the improvements needed to be implemented in the next sprint, now it says “as soon as possbile” which can be not necessarily in the next sprint, also adding the improvement action to the sprint backlog is left to the decision of the team, however I do feel having the improvements into the backlog will make them more likely to be acted upon.

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.

Section: Product Goal

My thoughts: While I applaud the concept of Product Goal I disagree with the fact that the Product Goal is represented by the Product Backlog. This thinking implies the product backlog is a completed artifact and no changes will ever occur in both, the content and order. I do believe there are better ways of capturing the Product Goal, like Roman Pichler’s Product Board.

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

Section: Sprint Backlog

My thoughts: While I am fan of Simon Sinek’s Finding your Why, I am not convinced with having a Why for the Sprint Goal, I do believe the Why should be part of the product goal, drafting a Why for the Sprint Goal seems redundant.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

Section: Product Backlog

My thoughts: This has been added in this Guide and for me implies focus on the value, the outcomes, not the outputs.

The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.

Section: Product Backlog

My thoughts: Promoting a long lived team with individuals that are 100% committed to one product.

The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives

Section: Commitment: Sprint Goal

My thoughts: Reinforce the concept of “Team” rather than “Group of people”, the latter very common out there unfortunately.

Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review thus supporting empiricism. However, an Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value

Section: Increment

My thoughts: A push for continuous delivery, no need to wait for the Sprint to end, which reinforces that the sprint review is not the place for work to be accepted rather work is accepted during the sprint, which is something I strongly agree with.

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

Section: Commitment: Definition of Done (DoD)

My thoughts: Encourages continuous integration throughout the sprint, before the DoD applied to the increment and implicitly to the PBI, now it’s explicitly to the PBI as well.

Final Note

These notes are not written expecting anyone to agree with them, if you disagree that’s fine, I do believe many of us will digest the Scrum Guide in different ways and having their own interpretations, regardless and if possible let me know what are your thoughts.

Link to the Scrum Guide: https://www.scrumguides.org/scrum-guide.html

✍ Check my other articles

My Top 5 F*ck ups as a new Scrum Master https://wilsongovindji.medium.com/my-top-5-f-ck-ups-as-a-new-scrum-master-daab8da0f29b

👋 About Wilson

I am a Scrum Master and Agility Coach, born in Portugal, with Indian origins and currently living in the UK.

I love to coach teams and individuals and get my my learnings at the coal face.

💬 Find me at:

Instagram: https://www.instagram.com/iamagilebeing
LinkedIn: https://www.linkedin.com/in/wgovindji/
My Agile Meetup: https://www.meetup.com/Newbury-Agile-Group/