A matter of Scrumantics

Much has been said questioning the appropriateness of the title ScrumMaster to describe a person who has attended a two-day Certified ScrumMaster (CSM) course.  I believe the title is appropriate. Here’s why:

ScrumMaster Doesn’t Mean “One Who Has Mastered Scrum”

The intended meaning of the title ScrumMaster can be interpreted in many ways due to the ambiguity of the English language. The word master, according to dictionary.com, has several meanings, including:

  • a person eminently skilled in something, as an occupation, art, or science (e.g. the great masters of the Impressionist period).
  • a person whose teachings others accept or follow (e.g. a Zen master).

Now, it doesn’t seem reasonable to believe that attending a two-day course can suddenly promote one to the ranks of the “eminently skilled.”  Acquiring skill takes time. Acquiring anything that could be classified as a skill almost certainly takes much more than two days’ time. We may conclude, then, that ScrumMaster is not intended to mean one eminently skilled at Scrum.

It’s a little easier to believe that attending a two-day course could place one in the position of being able to offer advice and guidance on a topic, and I think it must be a fairly common practice for a teacher of a fresh subject to perform his or her duties by staying a lesson ahead of the students. We might, therefore, accept that ScrumMaster means a person whose guidance about Scrum others are willing to accept or follow.

Other Masters

So far I haven’t heard anyone argue that the title master of ceremonies is a misnomer. And no one expects the typical emcee to possess a mastery of all things ceremonial. He is simply the person whom others have agreed will facilitate an event.

Likewise, a ringmaster isn’t expected to have somehow mastered the rings in the circus. Rather, he is the one who facilitates the performance and helps keep it moving.

Finally, a toastmaster isn’t one who has mastered the art of the toast, but instead is the person who announces or proposes toasts, or announces after-dinner speakers. Yet another facilitator.

What’s In a Name?

Ken Schwaber, in his book Agile Project Management With Scrum, says he chose “a strange name like ‘ScrumMaster’” because he “wanted to highlight the extent to which the responsibilities of the ScrumMaster are different from those of the traditional project Manager.” He goes on to say, “The ScrumMaster earns no awards or medals because the ScrumMaster is only a facilitator.”

Given this, it seems wholly appropriate to confer the title of ScrumMaster on a person who has attended a short course on Scrum facilitation skills. The title doesn’t convey mastery. At its simplest, it’s just an indicator of a way to employ the person bearing it.

Dude, where’s my user?

When crafting user stories, is it OK to name some non-human part of the system as your user? You may be creating requirements masquerading as user stories.

A common user story format

You are probably already familiar with this standard user story format:

As a <type of user>
I want <some capability>
So that <some benefit>

During the course of working with various development teams, I’ve run across stories like this more often than I would have imagined:

As the database, I want to have a Customer table, so that there is a place to store customer information.


As the system, I want to have an account object, so that account information can be seen.

The examples above certainly follow the standard format for user stories, but that doesn’t necessarily mean we’re getting all that we can from them. Either could be re-written as a simple requirement:

The database shall store customer information in a Customer table.
The system shall store account information in an Account object.

What we have here is a case of requirements masquerading as user stories. Note that both the faux and true user stories specify what is to be built. The difference is that the faux user stories leave out important information that true user stories convey, namely who the user is and why the story is being implemented.

These are important pieces of information, as they aid in determining that we’re building the right thing. In short, if a developer knows why something is to be built, and for whom, then he or she can make more intelligent decisions about precisely what is needed. And this can result in building something that is more useful and less expensive.

So if a simple requirement expresses the same thing as a so-called user story, why go to the trouble of bending the requirement into the shape of a story? Why do we see as many examples of faux user stories as we do?

My guess at the most common reason is that developers have been taught, or have led themselves to believe, that all features of a product must be expressed as user stories.

Another reason may stem from claims I’ve heard fairly often that are typically expressed as something like, “The work I do doesn’t have a user.”

Scrum says nothing about user stories

Scrum is the most commonly used framework for Agile development. And contrary to what many have been taught, Scrum says nothing about work items being expressed as user stories, but instead refers to them generically as Product Backlog items. Additionally, Scrum does not even require that all backlog items be of the same type or format, so a mix can be perfectly acceptable.

Now, to be clear, I’ve got nothing against user stories. I think they’re a very effective way to express the capabilities a system provides, and I use them almost exclusively when doing development work. My objection is to time-wasting efforts to express all work to be done in user story format.

Depending on your development environment and culture, you may be most comfortable populating your Product Backlog with a mix of true user stories and technical tasks.

My personal preference is to put only true user stories in the backlog, and to let any user story spark the creation of any necessary technical, under-the-hood stuff. But to do that, I have to engage in a mental exercise that I call:

Dude, where’s my user?

First, when I say “user” I mean some human-type person—not a data structure, a software component or other aspect of the system being built or a system that uses it.

User doesn’t necessarily mean a person interacting with some user interface. It means the person using your product, whatever it is that you produce. So if, for example, you produce web front-ends, your user probably is interacting with a user interface, and you should have little trouble identifying that user. If, however, you produce an API for a web service, your user is likely to be another developer, and you can write your user stories accordingly.

If you can’t easily identify one, you need to ask yourself, “Dude, where’s my user?” Because there probably is one out there somewhere. You may need to follow the path from your product through one or more other connected systems, until you find that person.

And If you can’t ultimately identify a user who benefits from what you are about to build, perhaps you should reconsider whether you’re building the right thing. Products are ultimately created for the benefit of human beings, so if you can’t find those people, either keep looking or stop building.

Scrum is not your process

To gain an understanding of what something is, it is often helpful to understand what it is not. This article outlines one of the important things that Scrum is not.


When training and coaching Agile practitioners, I often hear them use designations such as “the Scrum process” or “the Agile process” (by which they usually mean Scrum). Sometimes these are simply instances of using words casually, but in other cases it has turned out that what something is called substantially affects how it is thought about and used.

In my earlier training sessions, it seems that I met with quite a lot of resistance to the adoption of Scrum. After some digging I found that the primary source of such resistance was a general feeling that someone (typically management) intended to replace everyone’s existing work process with this new thing called Scrum, something of which they were (understandably) wary.

But once I made a regular practice of explaining that Scrum was not a replacement for their process, but instead a framework for inspecting and adapting that process, things tended to go more smoothly and the resistance pretty much went away.

You already have a process

You already have a process in place where you work. It may or may not be clearly defined. It may or may not be well understood. But, regardless of the work you do, you already have a process by which you turn some kind of input into some kind of output. Understanding your current process is important if you intend to make improvements to it.

Scrum is not your process

Let me repeat that: Scrum is not your process. That’s not to say, however, that Scrum is not a process. It certainly looks like a process in that it has well-defined steps which are performed in a specific order (i.e. Sprint Planning, Daily Scrums, Sprint Review, Sprint Retrospective). If you must think of Scrum as a process, then you might consider it a meta-process, in that it is a process which informs you about the state of another (your) process.

Your process may be something more like that shown here:Typical Process

As parts of a simple work process, these activities would need to be performed whether or not you use Scrum. Scrum can help you determine what things about that process might need to change (e.g. batch size, amount of work simultaneously in process, time between releases, etc.). Even so, Scrum isn’t intended to replace your process, but to augment it.

The founders of Scrum, as well as the current Scrum Guide, refer to it as a framework. I like that description, as it brings to mind some kind of skeletal structure or scaffolding that can be erected alongside your existing process in order to provide a vantage point from which to observe (inspect) the process and to change (adapt) it.

As frameworks go, I consider Scrum to be minimally intrusive. If you start practicing Scrum all at once, you will necessarily change some things related to your process (e.g. frequency of product releases, timing of meetings). In those cases, Scrum is not entirely hands-off as relates to your existing process.

I can easily imagine, however, a situation in which Scrum practices are brought online one at a time, in order to minimize disruption and make for a smoother transition. A team could, for example, start by adding Daily Scrums to their regular activities in order to begin inspecting and adapting work progress. Once that became routine, a team might add regular Sprint Retrospectives in order to begin inspecting and adapting the work process. And so on.

In conclusion

Organizations considering a transition to Scrum, and in particular those meeting with substantial resistance to such a change, may find that things go more smoothly if everyone involved understands that Scrum does not supplant any existing processes, but instead provides a point from which to view those processes in order to more easily improve them.