Is the Scrum Expansion Pack valuable?

Spoiler: it's not as bad as people are talking about

So, last month Jeff Sutherland and Co published an expansion pack to the Scrum Framework (I’ll call it SGEP for short). And truth to be told, it kinda flopped. We had about half a week of LinkedIn posts (mostly negative reviews) and it was over.

I didn’t want to write anything superficial about it, so I tried to read it carefully, with low expectations, and made some notes along the way.

It isn’t flawless…

Scrum is a framework and therefore is incomplete by nature. It gives us the task to complete it with practices, techniques and tools, and that’s the best part of the Scrum Framework in my opinion.

When I first heard about the expansion pack, I feared it would fill in the gaps and make the entire thing more prescriptive, and I think most people shared the same feeling. The authors managed to avoid that problem quite well, however, there were other problems I found.

It isn’t an expansion pack

Instead of just adding new information, the authors also changed some original concepts (ex: reverting to the use of the word roles instead of accountabilities).

It also says that the Product Backlog Refinement might be an event, which I really don’t appreciate since in my experience this kind of language fosters a mechanical behavior.

It’s not a single document. As the authors state at the very beginning:

“This document is a collection of independent works. Each section retains its original license or copyright status, as indicated.”

So the reading is a road full of bumps, and sometimes repetitive.

Other than that, I’d say it’s pretty much harmless.

It actually might help those struggling with Scrum

I’ve been teaching software development and Scrum since 2013, and I dare to say that a good deal of the questions people ask me during training sessions can be answered by the expansion pack.

And most of the time the SGEP managed to do that by expanding on the WHY of things, with a huge focus on empiricism.

More words make it easier to understand

Let me give you one concrete example: the Sprint Review. The original Scrum Guide is somewhat cryptic when it says:

“The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations” - Source: https://scrumguides.org/scrum-guide.html

It also says that The Product Backlog may also be adjusted to meet new opportunities.

In my classes I often take some time to discuss that: we need to determine future adaptations, which means changing the Product Backlog somehow. Therefore, a Sprint Review that doesn’t change the Product Backlog is something that should cause some reflection. Also, if the Sprint Review is a mandatory event, it means that the Scrum Team is not passively open to change the Product Backlog: they are actively searching for these changes.

The SGEP uses more words to describe that:

“The Product Backlog (the what) IS adapted” - Not “may also be adjusted”, but a strong “IS”.

This is the kind of difference that matters to me. Reinforcing that Scrum is about learning through experimentation so we can use fresh information to develop stuff.

Focus on Empiricism

The main problem most people have with Scrum, sometimes even without noticing it, is that they use the framework believing it will increase development speed. That often puts Product Owner and Developers in confrontation instead of collaboration. This problem is so common that the last Scrum Guide update change the term “Development Team” to “Developers”, and the explanation on why they did that was:

The goal was to eliminate the concept of a separate team within a team that has led to “proxy” or "us and them” behavior between the PO and Dev Team. There is now just one Scrum Team focused on the same objective, with three different sets of accountabilities: PO, SM, and Developers. — Source: https://scrumguides.org/revisions.html

Don’t get me wrong: I do like this change. But for beginners or even people who have been using the Scrum Framework in a dysfunctional way for a long time that’s not going to solve any problems. I mean, neither does the SGEP, but at least I think it did a better job at trying to achieve that.

For example, the SGEP:

• Clearly states that being a feature-factory or a discovery factory is not desirable

• Establishes that the Product Owner needs to effectively communicate outcomes

• The Product becomes an artifact with outcome based metrics

The SGEP also creates the Definition of Outcome Done, and I have mixed feelings about that. On one hand it adds yet another piece to the puzzle and makes the Scrum framework more prescriptive, but in the other hand it might be specially important for those beginning or struggling with Scrum.

Talking about that, the SGEP also provides some valuable insights for those starting or struggling with their job as Scrum Masters.

Provides better directions to Scrum Masters

The original Scrum Guide describes the Scrum Master in half a page. And if you have a good deal of experience with the framework that’s more than enough.

The SGEP however gets more into the specifics, but without limiting too much of your work. It states for example, that the Sprint Backlog should have enough work to get started, e.g., start with one or two Product Backlog Items toward the Sprint Goal. And you can read this sentence as: “there’s no Definition of Ready”.

Another example is the Product Backlog: while the original guide states that the Scrum Master must find techniques for effective Product Goal definition and Product Backlog management, the SGEP adds some valuable information on top of that, such as: A smaller Product Backlog often provides more Transparency or even the suggestion of using an Outcome Criteria for Product Backlog Items.

Then again, I know these are old news for some. Yet it makes obvious some of the things people often struggle to learn.

So, is it valuable?

It can be. But not for everyone. But reading it is a good exercise anyway, so go for it. The focus on empiricism is what made me like it, and it’s an expansion pack, which means… it’s optional anyways. You can also pick some of the ideas and apply them if you don’t want to add it all.

So, if you’re doing well with Scrum, you don’t need it. After all, you’re probably already doing most of the stuff described there.

If you feel the Scrum Guide is cryptic and leaves you with a feeling that it should elaborate a bit more on some aspects because you’re stuck, then the Scrum Guide Expansion Pack might be a good thing for you.