In November 2020, Ken Schwaber and Jeff Sutherland (the creators of Scrum) released an updated version of The Scrum Guide. There were quite a few changes. Here are the ones that Jim, Jit and David think are most significant to teams.
Addition of the Product Goal
The Scrum Guide says: “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 fulfil the Product Goal. … The Product Goal is the long-term objective for the Scrum Team. They must fulfil (or abandon) one objective before taking on the next.”
We say: Without a clear goal about what we are trying to achieve, and understanding our customers’ needs, there is an increased risk of us going in the wrong direction. The Scrum Guide’s encouragement to iteratively and incrementally move towards your product goals is a happy addition (it is something we’ve been encouraging in our training for the last 7 years!).
Self-managing over self-organising
The Scrum Guide: “Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how”
We say: This was always a bit of a discussion point: who decides WHAT the team will be doing? Being clear that the Scrum Team as a whole owns this makes it clearer and will hopefully encourage a greater shared responsibility, leading to increased success.
Explanation of Sprint Planning
The Scrum Guide says: “Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team… Sprint Planning addresses the following topics:
Topic One: Why is this Sprint valuable?
Topic Two: What can be Done this Sprint?
Topic Three: How will the chosen work get done?”
We say: Following on from the two points above, we like the focus on the value of the Sprint because it, again, reminds us of the overall outcome the team is striving for.
Focus on empiricism
The Scrum Guide says: “Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.”
We say: This change is an important one, as I believe empiricism is often the most overlooked part of Agile with Scrum. The obsession with estimation of a predetermined plan flies in the face of empiricism, and therefore Scrum. This change emphasises that in complex environments we cannot predict the future with any degree of certainty. It’s in these environments that Scrum becomes useful, as it’s designed to harness the power of empiricism and mitigate the risk of the things we don’t yet know.
Multiple increments released per Sprint
The Scrum Guide says: “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.”
We say: Another classic anti-pattern is the use of the Sprint Review as some sort of sign off or milestone phase gate meeting or change board. Calling out that multiple increments can be produced per sprint puts an emphasis on the everyday collaboration required to make that work, and the modern working practices needed to support that.
Scrum Master now a leader (rather than being called a servant leader)
The Scrum Guide says: “The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.”
We say: Hopefully means that Scrum Masters are encouraged to take greater action to improve the system as a whole rather than taking a backseat approach. The Scrum Master is not a team admin, but an agent for change through appropriate challenge and raising of awareness.
Software specific terminology removed
We say: Scrum and Agile principles are useful to all sorts of people in all sorts of industries. The removal of software specific terminology acknowledges the growth and application of Agile with Scrum outside of the software industry. Lawyers, Accountants, HR departments are all finding uses for it.
These are just our thoughts. What do you think? Click here to read The Scrum Guide in full.
These changes makes some sense, otherwise without goal to reach, we have been asked to make design to suit current changes specific to current sprint.. Some time it works and most of the time it fails.
Thank god now we have goal to reach by having multiple sprints..