I’m going through the complete Scrum Guide (2020 version) and turning it inside out. Hoping to find a satisfying answer to the question: “Does Scrum make sense?”
I started with “Purpose of Scrum” and “Empiricism”. I came to the conclusion that the premise of Scrum is sound. Then I looked into the Scrum Values, which can indeed bring the pillars of empiricism to life.
Then I discussed the Scrum Team. And I wondered how often a Scrum Team and its stakeholders work in an environment where all Scrum Values can be upheld, the team has no hierarchies and everyone understands the Scrum theory well enough to use the framework effectively.
The fourth topic was the Developers, who should own the What, How, and When to achieve a Sprint Goal. And the last two weeks I wrote about my issues with the Product Owner and Scrum Master accountabilities and asked if they aren’t too prescriptive.
I am more positive about the Sprint, the Sprint Planning, Daily Scrum, and Sprint Review. I believe the Scrum Guide 2020 makes very clear how they serve empiricism. Let’s now see if they continue this with the Sprint Retrospective.
The premise of the Sprint Retrospective
This final event of the Sprint wraps everything up. It is the moment where the Scrum Team looks at what they did in the Sprint and what they can learn from this. At the Sprint Review, the Scrum Team and its stakeholders inspect the outcome of the Sprint. At the Sprint Retrospective, the Scrum Team inspects the quality and effectiveness of the work.
The Scrum Guide has a very interesting line to discuss the Sprint Retrospective:
“The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.” - Scrum Guide 2020
It can’t be a coincidence that this reminds us of the Agile Manifesto:
There’s a lot to unpack here.
For starters, the words individuals, interactions, processes and tools are used in the exact same order. Secondly, the processes and tools aren’t skipped. The Sprint Retrospective isn’t only about the individuals and interactions.
Does this mean Scrum isn’t Agile? Because Scrum focuses on processes and tools? No, the Agile Manifesto is very clear about this. It states: “That is, while there is value in the items on the right, we value the items on the left more.” The Scrum Guide subtly hints at this too, because the individuals and interactions are mentioned first, then the processes and tools.
Also, you don’t want to avoid discussing processes and tools. Rigid processes and tools are often the reasons why teams can’t increase their effectiveness. From my own experience, I have seen Scrum Teams reach a plateau because they were unnecessarily delayed by the approval process. When wouldn’t discuss this approval process (and what to do about it) at their Sprint Retrospectives, they would not focus on the things that hold the Scrum Team back most. And that would make the Sprint Retrospective frustrating and later useless.
What to inspect and adapt
The Scrum Guide 2020 doesn’t tell us what elements to inspect. This is in line with how the latest edition of the Scrum Guide moved away from explaining HOW and instead focused on WHY and WHAT in a broad sense. After all, every Scrum Team is different and the framework is being used in all kinds of product environments.
I love how the element of empiricism is highlighted by the sentence: “Assumptions that led them astray are identified and their origins explored.” This shows us that Scrum Teams should do experiments and try out things to improve their effectiveness, inspecting this every Sprint (At the Sprint Retrospective). They do this by discussing what went well and what they could improve.
Then the Scrum Team should look at ways to run another experiment to improve their effectiveness, creating improvement items that may be part of the next Sprint. The previous versions of the Scrum Guide simply stated that at least one improvement item should be added to the next Sprint Backlog. That, however, is gone. I miss it because, in my opinion, it breaks the feedback loop. Because when you won’t do this next Sprint, why would you do it a Sprint later?
The Definition of Done
Almost casually, the Scrum Guide mentions the Scrum Team is supposed to inspect their Definition of Done (DoD) at the Sprint Retrospective. From my experience, this almost never happens.
I may have lived in a bubble (and including me, so would all my peers I discussed this topic with - within my organization and also within Serious Scrum), but I have rarely seen Scrum Team discuss the DoD at the Sprint Retrospective. I do admit it makes all the sense in the world that it happens here.
While the Sprint Retrospective would be the spot to discuss the DoD, there’s also the notion that the DoD should be part of the standards of the organization. This is mentioned in a section of the Scrum Guide that I will cover later. When the DoD is indeed an organizational standard, then this limits the influence a single Scrum Team can have on it. Therefore, follow-up discussions need to take place outside of the Scrum Team.
When the DoD is fully under the control of a Scrum Team, they can make decisions at the Sprint Retrospective itself.
The Sprint Retrospective is for the Scrum Team. This includes the Developers, the Scrum Master and the Product Owner. They are all a vital part of the team, so it makes sense they are all involved in the discussion.
I wish to point out that the Product Owners and Scrum Masters with multiple Scrum Teams would have multiple Sprint Retrospectives. I can imagine that this could become a burden for them. Especially when they also have to be in multiple Sprint Plannings. The Scrum Guide doesn’t discuss this and thus doesn’t come up with possible solutions. The scaling framework LeSS actually does this.
Only the Scrum Team is at the Sprint Retrospective. The Scrum Team is self-managing. Therefore it is logical they would work to improve their effectiveness themselves.
Length and timing
The Sprint Retrospective is the final event of the Sprint. This position at the end of the loop is logical as all other activities have ended. The Scrum Team is therefore in a position to reflect on everything that happened.
A month Sprint has a timebox for the Sprint Retrospective of 3 hours max. Shorter Sprints typically have a shorter Sprint Retrospective. That being said, I don’t think most Scrum Teams can have a meaningful discussion with everyone involved in 30 minutes. Still, I have seen many such short sessions. This hints at not taking the Sprint Retrospective too seriously.
The Sprint Retrospective section of the Scrum Guide makes a lot of sense to me. It clearly states why the event exists and what should be covered. It does not dive into details and that is logical in a version of the Scrum Guide that has many prescriptive items removed.
I only see some issues when a Scrum Team is one of multiple teams that work on the same product. They may not be able to conclude their discussions on their effectiveness and the Definition of Done without having discussions beyond the Sprint Retrospective. There are ways to organize Sprint Retrospectives with multiple teams, but this is not discussed in the Scrum Guide.
Thank you Willem, nice article. As a tester and custodian of quality of assurance, the definition of done is critical to me and should be bound to acceptance criteria of the User stories. The acceptance criteria should be inextricably linked to Given... When... Then statements aligned with the As a... I want.... so that ... BDD statements.