#68 Four Types of Scrum Work artwork

#68 Four Types of Scrum Work

Inspect and Adapt

June 3, 2026

Everyone knows that a Scrum team should do the value-added work of the product backlog. But there are other types of work that may or may not make it into that backlog, yet these types of work are critical for a well-functioning Scrum team.
Speakers: Mark Griffin, Earl Beede, Steve Tockey
**Mark Griffin** (0:04)
Hi, and welcome to another edition of the Construx Inspect and Adapt podcast. I'm your host, Mark Griffin, Director of Customer Solutions here at Construx. We're a team of software engineering experts founded by legendary author, Steve McConnell. Here at Construx, we believe every software team can be more successful delivering higher levels of business value. So today, we're going to talk about Scrum, and we're going to talk about the work done by Scrum teams and organizations. We're going to talk about it using four buckets of things that well-organized teams know very well.
Construx Senior Fellow Earl Beede and Principal Consultant Steve Tockey dig into this topic and largely agree on the segmentation that Earl proposes. So let's listen in.

**Earl Beede** (0:45)
The deal is this, is that if you read the Scrum guide, it will tell you that you need to do all kinds of work. There is certainly, and all that work can come off the backlog and you do this work. And it hints at various kinds of work, but doesn't necessarily spell it out very well. And it allows the team over time to try to discover all those kinds of work. So what we're going to hear today is sort of help you take a shortcut and give you some tools to help sort of manage that work, so you can get the most efficient team you possibly can using the Scrum framework. So we're going to take it Scrum, we're going to go a little Scrum-pros, and then we may even add some other things into it to help you understand the kind of work that's moving through.
So here's the deal. Scrum says, work comes out the product backlog, but what's on that product backlog? Well, obviously, there's stories or other product backlog items that deliver some sort of value. The product owner gets to decide of these things, which do I want the team to work on next? But there also could be other kinds of things like, defects. Defects are, to me, just previous stories that are no longer meeting the expectations, i.e. we thought we did it, and turns out we didn't do it. And so the product owner can decide, is this working on this defect more valuable than working on this new feature or new item on the product backlog item? But then they start saying, oh, you know, we also should be doing things in our retrospectives to say, wow, what do we do to improve the team? What do we do to make ourselves as a team more efficient taking things off the backlog and turning them into working software? So where's that work coming from?
We should also be constantly refining the backlog, getting stories into a ready state. We'll talk a little bit about how much of that. Where's that work being recorded?
Finally, there seems to be this weird, well, not weird, but this very common thing that stuff happens. We're thinking along, we've got an idea what's going to happen in one weekend or four days in, something happens that we didn't plan on, we have to deal with it.
Where do we record that work? This discussion is about seeing these different kinds of work that flow through a Scrum team and actually starting to actively manage it.

**Steve Tockey** (3:03)
Okay. Well, let me jump in here, though. I mean, I think you're using the term seeing the work, but I think that there's a difference between seeing the work for the purpose of planning it.
There's the seeing the work for the purpose of managing it. And then there's the seeing of the work for the historical purposes. Yeah, that's what we did, and that's what it cost us, and that's how long it took. That you got to be comprehensive across the, we're looking at it from a planning perspective as best we can. We are in the middle, we're trying to follow the plan we've laid out, even though it's only a two-week sprint plan. And okay, that sprints in the history books, but we still have to remember some stuff that happened because that's useful knowledge in the future.

**Earl Beede** (3:53)
I think one of the things I want to bring out in this discussion is that if you start seeing these sort of categories of work, you can do the planning part much more effectively. That is that you can start getting a better handle on where you're at and where you want to go in the near term. It also can help you in the daily executing part of it you're talking about, in terms of, are we spending the right amount of time in the right places? What's the next most important thing to work on? If I'm blocked here, where can I dive into the other categories of work to continue to try to produce some meaningful output?

53 more minutes of transcript below

Feed this to your agent

Try it now — copy, paste, done:

curl -H "x-api-key: pt_demo" \
  https://spoken.md/transcripts/1000651996090

Works with Claude, ChatGPT, Cursor, and any agent that makes HTTP calls.

From $0.10 per transcript. No subscription. Credits never expire.

Using your own key:

curl -H "x-api-key: YOUR_KEY" \
  https://spoken.md/transcripts/1000771064368