Scrum as Project Management

Experienced project managers, trained in the formal practice of project management, can be forgiven for feeling that they have entered the Twilight Zone on first encountering Scrum. While Scrum is a “process framework,” optimized for managing software projects, almost nothing about it seems familiar to someone with a PMP certification. And yet, if Scrum is about project management, its concepts should make sense to “classic” project managers.

How can we resolve this paradox?

Scrum Revealed

The apparent discrepancy between Scrum concepts and standard project management concepts is due partly to unfamiliar terminology, and partly to unfamiliar tradeoffs. Let’s look first at the terminology.


The terminology of Scrum reflects the practice of working in short, fixed-length cycles called Sprints, a set of which produces a Release of the product. With this understanding, we can translate Scrum terms into language more familiar to project managers:

Project Management Term Scrum Term
Schedule Sprint (or Release)
Scope Sprint Backlog
Work Breakdown Structure Task Breakdown
Productivity Velocity
Estimate to Complete Burndown Chart

The correspondence is straightforward. The burndown chart, for example, is just the graph of remaining planned work versus time, which should trend down to zero on the last day of the Sprint. The Sprint Backlog is the set of requirements (“Stories,” in Scrum) planned for implementation in a Sprint.


The key to understanding Scrum is to understand what success means for a software project, since the definition of success drives the process.

Project managers are familiar with the “iron triangle” of scope, schedule, and cost. For any project, changes to any of these affect the others. For example, if the scope (or effort needed to achieve it) was underestimated, cost and schedule may have to increase to achieve the scope.

The traditional definition of success requires implementing the planned scope, on schedule, and on budget. When this isn’t possible, the next best thing is to trade off, perhaps extending schedule, adding resources (cost), or reducing scope. In most cases, however, achieving the specified scope, or something close to it, is the most significant part of the definition of success for the project.

Software is different. Unlike houses, software products evolve incrementally, and modest increments of functionality can provide significant new value to customers. Moreover, customer needs can change rapidly, as some of today’s expectations turn out to be less important in six months than other needs that materialize three months out.

The definition of success for most software projects is not to deliver a fixed scope in six months, but to provide desired features quickly in response to urgent (and changing) customer needs. Responsiveness trumps scope as the most significant element of success.

The need to optimize responsiveness drives us to an agile concept of project management, characterized in Scrum by

  • Short cycles (Sprints)
    • Allows frequent course corrections in response to changing customer needs
    • Enables quick delivery of urgent customer needs
  • Fixed schedules (uniform length for Sprints)
    • Guarantees reliable scheduling of release-quality code
  • Completion of features in priority order within each Sprint
    • Guarantees top-priority features will be completed even if actual effort for planned features exceeds estimates significantly

Scrum trades off between scope and schedule by freezing schedule and adjusting scope as necessary. The reason we do not fix scope is because effort estimates for new-feature development have consistently proven unreliable in the software industry, and rather than fight the losing battle for more accuracy, we optimize for what we can predict (schedule, which helps in planning delivery dates), rather than what we cannot (the delivered scope).


The apparent departure of Scrum projects from standard project-management concepts turns out to be an illusion. In fact, Scrum processes are tightly-choreographed and involve careful planning, as any successful project does. The illusion of otherness arises from the unfamiliar terminology, and an unfamiliar tradeoff of scope versus schedule. In the end, an effective Scrum project is indeed following sound project-management practices.

Explore posts in the same categories: Uncategorized

7 Comments on “Scrum as Project Management”

  1. Kevin – I really liked the article and I think most of it is 100% correct …but I think you end up drawing the wrong conclusion IMHO.
    Scrum is NOT a project management approach it is a software delivery appoach. I agree with your mappings but there is a lot more in a project management approach e.g a business case, a quality plan/testing strategy etc etc.(see PRINCE2, PMBOK etc)
    Scrum works at the delivery level because a lot of ‘up front’ work has been done (or not done!) somewhere else. Where does the backlog magically appear from i.e. who thought it would be a good idea to create one?
    I hope your email kicks off a lively debate because I have been working in the agile space for over a decade now and this is one of the biggest misconceptions I come across.
    One final point – Scrum sits very nicely inside a traditional PM approach – because it is a perfectly valid ‘product delivery’ technique (but mixing these two is a debate for another day!)

  2. deepscrum Says:

    Keith – Thanks, and I agree with you. I am not claiming that Scrum is a complete project-management solution for the entire spectrum of activities that go into producing a software product, but that it is based on fundamental project-management principles, and can be understood as such.

    I draw a distinction between Scrum as a project-management framework (which defines a set of things that must be done if you are ‘doing Scrum’), and a Scrum-based process as it is implemented in a software company. The latter contains many elements that are not defined by Scrum, but which must be present for everything to work.

  3. Sue Uyetake Says:

    Thank you deepscrum,

    I like the conversation in this. Makes sense, and it would have cleared up the bewildered looks I saw among my Scrum Master Certification classmates who were mostly Project Managers. I was one of only QA professionals in the room. June 2009 onsite at Rally.

    My friend pointed out your article to me. This is where my Poetry Blog (on IT subjects) is as well.

    – Sue Uyetake, Boulder/Denver area

    • Kevin Thompson Says:

      Hi, Sue. You write poetry about IT? I have to see that! (Just did–very interesting!)

      I think the divide between classically-trained project managers and scrum masters needs to come to an end. It isn’t that hard to bridge the gap, and I’m glad you’ve found this discussion interesting.

  4. Scrum Says:

    Scrum development can also be compared with music composition. Here is the interesting viewpoint by Paul Goddart:

    • Kevin Thompson Says:

      That’s an interesting idea. It fits with the need for careful choreography of the steps of a Scrum process, and also with the notion of a cadence.

  5. johnsonkee Says:

    Hi Kevin,

    I’m writing a blog about PMP Certification and definitely wouldn’t have thought about including a section about Scrum as a tool for project management.

    I like the distinction you made about it being a project management framework and a Scrum-based process. It’s important to remember that tools can never replace concepts and fundamental foundations which allow the tools to be useful in a particular context.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: