10 things I found refreshing while revisiting Scrum and Kanban guides

I learned Scrum 15 years ago. Since then, I have been treating its set of prescriptions and practices as rather fixed. Until recently, I saw no incentive to revisit them.

At the same time, projects I took part in usually didn't use proper Scrum. Rather, they ended up with some custom Agile process supplemented with selected Scrum practices.

People I met, whether Developers or Project Managers, had various issues with Scrum. Some practices seemed too restrictive (strictly month-long Sprints, fixed Sprint Scope), vague (a difference between high-level and low-level tasks), or not that helpful (Story Points).

Recently, I was preparing for the Professional Scrum™ with Kanban Certification. I used it as an opportunity to refresh my knowledge and compare it with current Scrum guides. I was happy to discover that in the meantime, Scrum did actually adapt to these complaints.

Below is a subjective list of 10 things I found refreshing or surprising when going through the learning materials:

• When to release
• The role of Sprint Review
• Is a life demo necessary
• Shorter Sprints are officially recognized
• Sprint Scope is negotiable
• Quality is not negotiable
• Story Points are rendered obsolete
• Service Level Expectation
• When tasks are too fine-grained
• Value vs Work

Later, I discuss each point in detail. The bottom line is — even if you're a seasoned Agile practitioner, it's still worth it to return to basics from time to time.

But first, let's quickly recap some basic facts about Scrum and Kanban.

Scrum and Kanban

Scrum and Kanban are two popular implementations of Agile practices. They may be regarded as alternatives but they can work well together. They tend to focus on different aspects of the process. They both strive for improving its observability and adaptability. But while Scrum emphasizes the importance of team collaboration, Kanban focuses on optimizing the flow. (For a detailed comparison of Scrum vs Kanban, see for example here and here.)

Back in the day, I considered Kanban a lightweight, more flexible alternative to Scrum. In one of the projects, we resorted to Kanban, having a client constantly coming with more and more expedient tasks in the middle of a Sprint. Maintaining a fixed Sprint Scope was simply impossible and Kanban seemed the last resort before descending to utter chaos.

In 2020, the Scrum organization updated the official Scrum Guide. The update included some nontrivial changes compared to what I originally learned. Now, I was happy to discover that the Scrum organization also prepared an official guidance on how to merge Scrum and Kanban into a consistent framework. It is described in the Kanban Guide. It takes complete Scrum as the foundation and extends it with Kanban to improve the overall efficiency and predictability of the flow.

Note: There exists an alternative attempt to merge Scrum and Kanban, known as Scrumban. Contrary to the framework described in the Kanban Guide, Scrumban centers around Kanban practices with an addition of selected Scrum ceremonies. Thus, it is not a full Scrum implementation.

Scrum and Kanban work well together. I learned to think about them as a combo, and that's how I treat them in the discussion below.

My reflections

When to release

Scrum uses the notion of Increment. An Increment represents a selection of work that can be developed during a single Sprint. Each Increment must provide a value, be concrete, additive (to all prior Increments), and usable (see: Scrum Guide, "Increment"). As a result, each Increment can be individually releasable, at least in theory.

Now, according to Scrum, when is the right moment to release an Increment? Specifically, should you wait with the release until after the Sprint Review?

The answer is no. It's perfectly fine to release in the middle of a Sprint, even multiple times. To quote from the Scrum Guide:

"Multiple Increments may be created within a Sprint. The sum of the Increments is presented at the Sprint Review (...). However, an Increment may be delivered to stakeholders prior to the end of the Sprint." (Scrum Guide, "Increment")

A similar quote from the Kanban Guide:

"It’s a common misconception that teams can only deliver value once per Sprint. In fact, they must deliver value at least once per Sprint." (Kanban Guide, "The Sprint")

It is a change from previous Scrum Guide versions, which implied treating a whole Sprint as a single Increment.

It means that Scrum can well be used by teams practicing frequent releases or Continuous Delivery. It relates to the role the Sprint Review plays in the Scrum framework.

The role of Sprint Review

Scrum Guide defines Sprint Review as a prescribed event, when the team presents the results of their work to key stakeholders.

But, what if the stakeholders don't like what they eventually see at the Sprint Review? Shouldn't you wait with the release until stakeholders have an opportunity to receive and approve the work?

Again, the answer is no. If you want to practice frequent releases then there are other means of validating the work during the Sprint, like code review and acceptance tests. The current Scrum Guide explicitly states:

"The Sprint Review should never be considered a gate to releasing value." (Scrum Guide, "Increment")

The Sprint Review is about communication. It allows the team and the stakeholders to check where they are comparing to where they planned to be at the beginning of the Sprint:

"During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. (...) The Sprint Review is a working session, and the Scrum Team should avoid limiting it to a presentation" (Scrum Guide, "Sprint Review")

Is a life demo necessary

It's assumed that the Sprint Review should contain a life demo of the accomplished work. Though not explicitly prescribed, it was often presented as an integral part of Scrum practices (see: Agile Project Management with Scrum, chapter 5, “The Product Owner”).

It turns out that the Scrum Guide does not explicitly mention any requirement for a life demo. So, the team may well choose a different way of presenting the results that suits them better. Again, a demo here is not about gaining approval, but rather to facilitate the discussion.

Having said that, a life demo provides an important value: it helps the team stay focused on delivering a working piece of work. Here, they can't avoid an issue of "the last mile" — all those pesky little details and boring side-tasks that need to be completed in order for something to actually work. And preparing a scenario for the demo encourages them to look at their deliverables from the client perspective.

Shorter Sprints are officially recognized

Back then, Scrum was prescribing strictly 30-days Sprints (see: Agile Project Management with Scrum, chapter 1, “Scrum Flow”). When combined with frozen Sprint Scope, it made Scrum seem quite rigid. Some teams found it too rigid in their contexts.

Soon, some of them started adopting shorter time-ranges. Though frequent, such adaptation was a departure from official prescriptions. Now, shorter Sprints are officially recognized in the Scrum Guide as a valid possibility. (It turns out that they were already present in the first version of the Scrum Guide from 2010.)

Actually, monthly Sprints had their merit. Spending two days for Sprint events at the beginning and the end of each monthly Sprint may be acceptable. When Sprints become shorter, these events start taking a relatively larger portion of time. For this reason, the Scrum Guide now suggests adjusting these events to the duration of the planned Sprint.

Sprint Scope is negotiable

Something I found even more surprising is the fact that the Sprint Scope can actually be negotiated in the middle of the Sprint. As stated in the Scrum Guide:

“Scope may be clarified and renegotiated with the Product Owner as more is learned.” (Scrum Guide, "The Sprint")

It's possible to add a task with higher priority or resign from some part of the Scope. On the condition that the overall Sprint Goal is not affected by the change.

This is a good example of how Scrum became more flexible. Throughout the Scrum Guide, its authors use the notion of empiricism as the guiding principle. Empiricism is based on experimentation. There are things about the work at hand you're only going to learn by experimenting with it. If you accept that, you need to be open to the possibility that what you learn may affect the plan.

A Sprint can even be canceled with the consent of the Product Owner.

"A Sprint could be canceled if the Sprint Goal becomes obsolete." (Scrum Guide, "The Sprint")

Quality is not negotiable

What's not negotiable is the Quality — as defined by an existing Definition of Done. This actually never changed. Note that the Definition of Done itself is a result of an agreement among the Scrum Team (including the Developers, the Product Owner and the Scrum Master). And it can be adjusted to accommodate changing requirements.

But if a task doesn't meet the agreed Definition of Done, you can never treat it as completed.

"If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration." (Scrum Guide, "Commitment: Definition of Done")

When you find yourself with open items at the end of the Sprint, it doesn't necessarily mean that you blindly invalidate the work and go back to square one. Rather, before you continue, you should stop for a moment to look around and make sure that the priorities haven't changed.

Story Points are rendered obsolete

When I first learned Scrum, I was taught to use Story Points for estimations. Actually, Story Points are not part of the official Scrum practices. But, back in the day, they were ubiquitous in learning materials.

Now, I've met with quite a lot of criticism related to Story Points. Andy Hiles provides a comprehensive list of arguments in his book (see: Applying Scrum with Kanban, chapter 1, “Story-Points”):

• "The first problem here is the amount of time teams take to estimate the work (...) This time could have been far better spent doing the work to uncover the complexity."
• "The second problem is that teams lose focus on creating outcomes; over time, Scrum Teams talk about the Points rather than (...) outcomes they are building."
• Also, by trying to give precise estimates the Story Points give false sense of certainty. Estimates always assume some level of uncertainty, but with Story Points, there's no way to communicate the risk to the client.
• Story Points may actually negatively affect the work culture: When managers expect that every task is estimated upfront, the team may become too scared of saying that for a given problem they simply don’t know and just need to start working before they get back with an estimate.
• And, in spite of all the effort, the estimates provided by Story Points are not that reliable. As Andy Hiles put it, they are just guessing at guessing.

Check: Planning Poker - how to streamline and gamify your estimation process

Service Level Expectation

Now, I've learned about Service Level Expectation as an alternative approach to estimations. Contrary to Story Points, SLE is based on historical data (facts), specifically historical Cycle Time:

"Cycle Time: The amount of elapsed time between when a work item starts and when a work item finishes." (Kanban Guide, "The Basic Metrics of Flow")

For example, if you know that of all work items you have already completed, 80% took 5 days or less, you can use it as a forecast: that any of the future tasks should also take 5 days or less with 80% probability.

As you can see, information about the probability is naturally included into SLE. It gives you a convenient way of communicating the risk to the client. In case you cope with tasks of various categories the approach easily generalizes: just compute SLE for each category separately.

Obviously, the approach is vulnerable to variance in Cycle Times. It works best if the variance is small, meaning that most items take roughly equal time to complete. Interestingly, Kanban is not trying to stabilize the variance of Cycle Times. Instead, it focuses on optimizing the Cycle Times themselves, i.e., trying to complete each item as quickly as possible.

The significance of optimizing Cycle Times has an important, independent confirmation in the "State of DevOps" report (see: Modern Software Engineering, chapter 3, "The Importance of Measurement"). Cycle Time closely resembles Lead Time — one of four measures which the report shows to statistically correlate with teams' performance.

When tasks are too fine-grained

Back then, I was actually quite happy with using Story Points. Especially when compared to estimating in man-days. My own observation was that the estimation gets better when you split the item into smaller tasks (total estimation usually goes up, sometimes significantly). When using Story Points, you may tend to split items as much as possible at Sprint Planning.

It may work well when the work is repeatable and the topics are known but it is vulnerable for unexpected problems and surprises (the "unknown unknowns" vs "known unknowns"). One may argue that attempting to answer all questions during the Planning session results in tasks that are too fine-grained, leaving no place for experimenting during the development.

Interestingly, using Kanban metrics and Service Level Expectation might also lead to work items being too fine-grained. It would happen if optimizing for the Cycle Time metric weren't countered by another rule. That is, by stating that each work item must represent value as opposed to work.

Value vs Work

Scrum Guide and Kanban Guide both distinguish between value and work, and they both focus on value:

"The Scrum Team turns a selection of the work into an Increment of value during a Sprint." (Scrum Guide, "Scrum Definition")
"Kanban: a strategy for optimizing the flow of value through a process" (Kanban Guide, "Definition of Kanban")

Value is what is discussed with a client and at Sprint Planning, and what makes up a Product Backlog and Sprint Backlog. In consequence, each Backlog item needs to independently provide a concrete value to the client. For example, it will represent a whole User Story, rather than a technical task making up a part of the Story. Also, a Backlog item doesn't have to be defined with too much of a detail. Specifically, you don't have to define every implementation detail upfront. It leaves room for experimenting and making decisions during the Sprint.

What does it mean in practice? You may consider maintaining two levels of items on your Board:

• high-level items representing value,
• and related low-level items representing parts of work.

From the Scrum perspective:

• Sprint Scope would include the high-level items,
• adding or removing a high-level item mid-Sprint would mean changing the Scope which requires negotiations among the Team,
• but adding low-level items is free since it wouldn’t affect the Scope.

From the Kanban perspective:

• Kanban requires to set limits for work items in progress; you may well decide to focus the limits on the number of open high-level items,
• and observing the Cycle Time of high-level items is most important since it represents the time to deliver actual value.

(For further discussion of Value vs Work, see here.)

Summary

So, these are my reflections I noted down when refreshing my understanding of Scrum and Kanban for the sake of the exam. Obviously, they don't exhaust the topic. All in all, I'm glad I took the exam because it was a great opportunity to refresh my knowledge and learn something new.

Here's a list of sources I referred to in the article:

• Scrum Guide (scrum.org, 2020)
• Kanban Guide (scrum.org, 2021)
• Ken Schwaber, Agile Project Management with Scrum (Microsoft Press, 2004)
• Andy Hiles, Applying Scrum with Kanban: A Pointless Book! (Independently published, 2021)
• David Farley, Modern Software Engineering: Doing What Works to Build Better Software Faster (Addison-Wesley Professional, 2021)

And if you are considering taking a Scrum exam, I can recommend the Professional Scrum with Kanban Certification as an alternative to the regular Professional Scrum certificates. The Scrum site provides a comprehensive list of learning materials for the exam.

Reviewed by Bartłomiej Turos