Type C Scrum explained

25 Apr, 2007

This blog entry is another insight that came out of talking with Jeff Sutherland when he was our guest at Xebia.
Pictures can say more than a thousand words, but they can also confuse things. One of the things I didn’t get is Type C Scrum, and the only thing I had to go on was a paper by Jeff, and a picture that is generally used to visualise types A, B and C. I now realize that the picture actually made it more difficult for me to understand Type C…
It’s supposed to be the most advanced and difficult form of Scrum, and Jeff explained how Type C works at PatientKeeper. Type C is actually a Scrum in a Scrum in a Scrum, or (as Jeff put it) a wheels within wheels thing.

The well-known picture is the one below: note how it shows a Type C as overlapping ovals of the same size. So are you just overlapping Sprints?
Scrum types
Actually… nope. Type C something else entirely.
There is a parallel with the picture that is generally used to explain the daily Scrum, where the daily Scrum is a small gear, turning once every day, meshing with a larger gear, turning once every month. I now picture Type C as a stack of these gears: the daily Scrum, the weekly cycle, the monthly cycle, and the quarterly cycle (at least, this is the set of cycles used at PatientKeeper).
Items of the backlog get assigned to one of these cycles based on their priority and urgency. There’s the hold-the-line priority, where all work is dropped to fix a critical issue. Then there are high-priority backlog items that need to be delivered this week, “regular” items for the monthly cycle, and the more strategic improvements and changes for the quarterly cycle.
A team member will work on backlog items in that order: hold-the-line work first, then the weekly items, then the monthly items, and finally the strategic items. Jeff explained that this is a nice incentive for team members: if they get the high priority stuff done, they have time left for, as Jeff put it, “the really interesting stuff”: sit back, take a breather and think about how to make the product better, cleaner and cooler.
So the real Type C picture should be this one:
Wheels on wheels
I have never done Type C, but I guess that the biggest challenge is to make sure that the short term stuff does not squeeze out the time for the long-term items. I don’t think that assigning items to one of the cycles should be too much of a problem.
I hope that you have less trouble understanding Type C. I know that the new visualisation did the trick for me…

Newest Most Voted
Inline Feedbacks
View all comments
Guido Schoonheim
15 years ago

Thanks Serge! I had the exact same problem with the first illustration. This way it finally makes (lots of) sense.


[…] Scrum in the project. It may be a little different in maintenance project as it generally follows Type C Scrum. The documentation is generally available on project […]

Fabrice Aimetti
10 years ago

Hello Serge,
I have translated your (nice) post into French :
Thank you.


[…] Scrum in the project. It may be a little different in maintenance project as it generally follows Type C Scrum. The documentation is generally available on project […]

7 years ago

The isolated cycles in Jeff’s diagram are analysis, design, coding, testing…

Jeff Sutherland
Jeff Sutherland
5 years ago

Type C Scrum was introduced in this paper Future of scrum: parallel pipelining of sprints in complex projects. J. Sutherland. Agile Development Conference (ADC’05)
Pages: 90 – 99, DOI: 10.1109/ADC.2005.28
Two core issues where introduced – the concept of Metascrum and driving repeated deployments every sprint through automated testing, operations, and deployment.
Today, this has evolved into Scrum@Scale where we use the MetaScrum for integrating management with the Scrum teams and DevOps where everyone now has the tools to deploy at will by totally automating testing, operations, and deployment.

Explore related posts