With the latest update to the Scrum Guide in November of 2020, there were some significant changes. For example, the prescriptive nature of the three question format for the Daily Scrum.
Scrum Guide 2017
- 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?
Scrum Guide 2020
“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.”
“The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.”
Those questions may make sense and hold some value for some people, but it turns that Daily Scrum into a status report meeting. And that is not the intended purpose, so I was happy to see that be removed from the Scrum Guide. But I could also argue that the meeting is pointless if you are working as a team since you would all be focused on the same thing, working collaboratively throughout the day, leaving little need for this type of meeting…
Now the point of this post is to discuss the changes in the Scrum Guide regarding Increments.
Scrum Guide 2017
“The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.”
Scrum Guide 2020
“An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable. 12 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. Work cannot be considered part of an Increment unless it meets the Definition of Done”
Now this sounds great to me since the previous version of the Scrum Guides wording led people to take the Sprint Review as an approval gate. Literally preventing teams from delivering anything of value before the Sprint Review meeting where you would gain said approval. That doesn’t sound very agile to me.
But it does raise the question, what makes a usable increment?
- Is a requirements doc usable?
- Is the completion of a research item usable?
- Is a prototype usable?
- Is a testing plan usable?
- Is an API usable?
- Is a Database schema change usable?
I guess the point I am getting at is even waterfall produces some “usable” outputs at the end of each phase that are usable to the next phase. I do not want this to be an attack on waterfall or Scrum, I am just questioning some of the wording that is being used. This is where I start to drive a divide between Scrum and Agile.
Maybe “usable” is supposed to imply from the users perspective. I would like to believe this since we are trying to work in an agile way, and with a framework that was created by two of the signatories of the Agile Manifesto for Software Development, with a focus on user value. (Even though Scrum as a framework is often falsely equated with Agile given that Scrum is in reality a very rigid framework in my opinion, but that is another post.) And then one could even make the argument that this is why we use Stories (User Stories) to define our work. We approach the work from the domain level experience of what the user values as usable software. If you said that is what defines a “usable increment” then I’ll buy that since that aligns with core values and principles of agile.
But, the Scrum Guide never mentions the words Story, Stories, or User Stories anywhere in it. Scrum lists all things as Product Backlog Items (PBI’s). 13 times by my count in the 2020 Scrum Guide. This doesn’t necessarily bother me because it allows that divide to grow more between Scrum and Agile. But it does, in my opinion, take Scrum and puts it squarely in the realm of “just another project management framework”.
This watered down wording leaves plenty of room for interpretation and for you to decide what is valuable to you and not necessarily to your user. Which is fine, but if you are using Scrum in an attempt to work in an agile way, and we decide that a “usable increment” includes a “requirements doc” or a “testing plan” then I think we are far beyond the intent of Agile.
Now I could be completely wrong or interpreting Scrum incorrectly, but I have been over this a few times and have had multiple conversations on this topic and it still gets me scratching my head.
As always I welcome comment and conversation on this, and hopefully someone can sort me out on this in a logical way.
Chris Pipito 