A couple of days ago an update to the Scrum Guide was published by Ken Schwaber & Jeff Sutherland. I will try to give a short overview about the important changes:
Scrum relies on transparency. Decisions to
to optimize value and control risk are made based on
the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase
While it was clear before that Scrum artifacts are meant to be transparent, the transparency is now seen as mandatory. This means anyone on the Scrum Team and the stakeholders must have access and be aware of the current state of the documents. A big part of the Scrum Master’s job is establishing this transparency with the team and the organization.
There are two major changes for the Sprint Planning. The first one is that the idea of it being two different meetings – Planning One and Planning Two is gone. It is now more seen as one meeting that starts with Topic One answering:
What can be done this Sprint?
while Topic 2 answers
How will the chosen work get done?
A big difference here is that in the past the Product Owner was an optional part of Planning Two, now he is supposed to be there for the whole Planning.
The Sprint Goal
Something new is the addition of the Sprint Goal to the Sprint Planning. This means that the team gets a common goal to work toward in the form of items that have a cohesive meaning instead of completely independent topics being worked separatly.
Backlog Refining instead of grooming
Another change is the idea that the backlog should no longer be groomed but instead be refined. Refining a backlog item means that it is well enough understood and small enough to be a part of the next Sprint Planning and be selected for that Sprint. They are now „ready“. No storys that are not ready should be allowed into a Sprint Planning.
It has been clarified that all events in a sprint are timeboxed and that they should last for a maximum of X time. But they can be shortened if they are clearly finished and continueing would just „waste“ time.
The sprint itself however can not be shortened or extended.
The Daily Scrum is now seen as more of a planning event instead of a mere status meeting. It is how about the Development Team will reach the Sprint Goal by todays work. The three questions have therefore been slightly changed:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
The Sprint Review changes from being focused of what has been done that sprint to what has been done and what should be done next. Part of the meeting is now that the Product Owner discusses the Backlog and projects likely completion dates. After this the whole group – Scrum Team & stakeholders discuss together on what should be done next as input for Sprint Planning.
Also it is reviewed what has changed for the products market situation and if that has influence of the order of the backlog. This is followed by a view of the products timeline, the budget, the potential capabilities and the market situation at the planned release time of the product.
This all results in a revised Product Backlog that will increase the value of the next sprint.
I really like many of those changes. More planning, more adjusting to change is just a thing we need to do in ever changing environments.