12/6/2006 Page 1
Project Management and Scrum – A Side by Side Comparison
by Anne Loeser, October 2006

For decades, software development projects have followed the classic “waterfall” method in which software
development initiatives were carefully analyzed, designed, documented, coded, tested, and ultimately delivered
to the customer – sometimes years after inception. By then, it was not uncommon for business needs to have
changed and for the resulting system to fall short of customers’ expectations. According to the Standish Group,
software development projects have an overall success rate of 34%. In response to this rather disappointing
approach to software development, “Agile” methodologies – which are light on documentation and formality -
began to emerge in the 1990’s. Scrum, which is one of several Agile approaches, was first developed and
presented in 1995 so it is relatively novel when compared with traditional software development processes
which have been used for decades. The purpose of this paper is to compare traditional waterfall project
standards and deliverables with those in Scrum, and to contrast the Project Manager’s role with that of the
Scrum Master.

Traditional Project Management at a Glance:
According to the Project Management Body of Knowledge (PMBOK), a “project” is a temporary endeavor
undertaken to create a unique product or service.”
1
Projects are typically divided into phases in order to
provide better control of the project’s progress and deliverables; each phase has a prescribed set of deliverables.
Collectively, the project phases are known as the “Project Lifecycle.”

Project Management is a term encompassing the application of skills, tools, techniques, and knowledge applied
to a project to meet or exceed stakeholder expectations. Project Managers typically oversee the following
aspects of a project:

1. Project Scope, which ensures that all the required work, and only the required work, is planned, defined,
documented, and delivered to the customer’s satisfaction.
2. Project Schedule, the objective of which is timely delivery of the product or service. It entails activity

Release Plan is similar to the traditional Project Schedule in that it identifies product features and the
corresponding timeframes (possibly phases) in which features will be delivered, albeit at a higher level
than traditional Project Plans. Quality-related features, risks, dependencies, constraints, assumptions
and issues may also be identified and documented as part of the Release Plan, which is generated by the
Product Owner and Development Team.
• A Sprint Planning Meeting in which backlog items are selected for iterations(s) called Sprints (which
are usually 30 days in length). Product Owners and the Development Team finalize features and
identify related tasks to be completed within the Sprint, and provide task estimates as part of planning.
When applicable, the Release Plan will be referred to during the Sprint Planning Meeting. Risks and
issues are also discussed at the Sprint Planning Meeting. The resulting Sprint consists of condensed
Planning, Development, Testing and Release Project Lifecycle tasks and activities.
• A living Sprint Backlog or Sprint Plan of tasks to be done within the Sprint. When tasks are identified
in the Sprint Planning Meeting or during a Sprint, they are entered into the Sprint Backlog. The Sprint
Backlog is related to the Project Scope mentioned above in traditional projects because it encompasses
activities and deliverables that need to be completed within the Sprint. When a particular Sprint is part
of a Release Plan encompassing multiple Sprints, its backlog may be compared to the deliverables
within a traditional project phase. The product Owner and Development Team create the Sprint
Backlog.
• A brief daily Sprint Meeting or Scrum, at which each team member’s progress is disclosed, upcoming
work is described and committed to, and impediments are raised. The Sprint Backlog is updated at the
Sprint Meeting, and business partners are frequently members of the Scrum team. The daily meeting is
the primary formal means of communication among the team, although informal meetings and other
forms of communication throughout the day are encouraged.
• A Demo at which Product Owners (and occasionally developers) demonstrate accomplishments during
the Sprint. Each Sprint should deliver a usable product increment. The Demo has no equivalent in
traditional projects.
• A Retrospective, at which team members reflect about the past sprint and make recommendations about
future improvements or changes. The Retrospective may be loosely compared with Post-
Implementation Reviews in traditional projects.
Scrum is facilitated by a Scrum Master whose primary responsibility is to remove obstacles hindering the team

The following table provides a side-by-side comparison of Project Management practices and deliverables with
respect to the traditional waterfall approach vs. Scrum.

Project Management Practices and Deliverables: Traditional & Scrum

ITEM TRADITIONAL WATERFALL SCRUM
Processes

Project Planning
(Scope,
Schedule,
Communication,
and Human
Resources)

. There is no equivalent of a Vision statement in
waterfall projects, although a corporate Strategic
Directive may be derived to specify direction and
ultimately the projects that support it.

. There is no specific equivalent of a Roadmap in
waterfall projects, although companies may generate
their own internal Strategic Plans in support of
Strategic Directives.

. Once a project has been justified and approved, the
PM leads the requirements gathering and time
estimation effort by holding extensive meetings with
Business Analysts, designers, architects, IT, Product
Owner(s) and key stakeholders. The PM oversees the

5 Levels of Planning:
. Vision (a brief statement specifying direction)
derived by Product Owner
. Roadmap (a brief document consisting of 1 year’s
worth of high level features) created by the Product
Owner & Executives . Release Plan to deliver larger initiatives across
multiple Sprints, compiled by the Product Owner and
Development Team. The effort is usually facilitated
by the Scrum Master.
. A Sprint Plan identifying all tasks & estimated task
hours is created by the Product Owner &
Development Team – not by the Scrum Master. It is
updated daily by the team at the Scrum meeting once
the Sprint commences. Only estimated hours
outstanding are tracked – actual hours are neither
requested nor recorded.

. Daily Sprint Meeting or Scrum. (15 min.) which is

Analysis and Contingency Planning, and usually
maintains and publishes a Risk Document.

. Only the Sprint team can change features and tasks
within a Sprint, and only if jointly agreed by all
members of the Sprint Team. Otherwise the
requested item is added to the Product Backlog.

. The team performs risk management activities
before starting development work. Risk may be
discussed during Release, Sprint Planning, and/or
daily Scrum Meetings.
Task Ownership;
Actuals/Estimates
(Schedule and
Human
Resources)
. The PM creates a Project Plan with tasks,
assignments, and estimated hours. The Project Plan is
reviewed with the Project Team and baselined once
all parties concur. Deviations from the baseline must
be explained and addressed by the PM.

. The PM periodically updates the Project Plan with
actual hours and new estimates, as well as with
additional tasks based upon team input. . The PM acts as a coach and leader for the project
team and assists team members in overcoming

the next Sprint. The Sprint itself is never extended,
nor does the Scrum Master negotiate for additional
resources or time.
Project Budget
(Cost)
. Typically, a project must provide ROI in order to be
launched, at which point a Project Budget is derived. . The PM usually manages the Project Budget, which
includes resource costs, technical costs, consultancy,
departmental charge backs (if appropriate), and other
expenses. Potential overruns must be justified and
approved, and/or the PM must negotiate adjustments
to the aforementioned 5 items in order to meet
budget.

. At the beginning of each Sprint, the Product Owner
may be asked how much they want to spend on the
Sprint. Based upon the answer, the team may use
cost as a guideline when selecting an appropriate
amount of work from the Product Backlog to be done
in the Sprint.

. No mention could be found in Scrum materials
regarding Sprint-related budgets. It is assumed that
each corporation adopts its own practices with
. In Scrum, QA personnel may be needed for testing
12/6/2006 Page 6
become engaged in the testing phase. in every Sprint, which can create a resource burden
on this group.
Documents

Cost Benefit
Analysis
. A Cost Benefit Analysis (CBA) may be submitted
and approved in order for a project to be done. The
PM may or may not be chartered with compiling this
document. ROI is typically a key factor with respect
to whether an initiative is approved for development.
. The author could not locate a CBA equivalent in
Scrum.
Requirements . Related documents include but are not limited to:
* Feasibility Study
* Statement of Work
* Project Scope
*. Requirements Document
* Functional Design
* Detailed Design
* Test Plans and Test Cases, which are sometimes
done at the Requirements Definition Phase


receive or be involved in them, and how often.
. There is no equivalent to the Communication Plan
in Scrum.
Budget
Spreadsheet
. Generally the PM is accountable for overseeing and
reporting the Project Budget.
. The author could find no mention of Project Budget
maintenance with specific respect to Scrum.
Issues Log . The PM is accountable for compiling and updating
the Issues Log and for overseeing that issues are
resolved.
. Issues/obstacles can be raised at any point, and the
Scrum Master is responsible for documenting them,
removing obsacles, and overseeing their closure.
Risk Analysis . The PM is accountable for compiling and updating
the Risk Analysis and Contingency Plan, and for
navigating the team safely through the risks in order
to deliver the project successfully.
. Risks are documented by the Product Owner and
Development Team in the Release Plan. The entire
Sprint Team is responsible for resolving risks
throughout the Sprint.
Project Plan . The PM uses the Project Plan to derive the
preliminary project schedule. The PM then baselines
the schedule and meets periodically with the team to
update the Project Plan with actual hours and revised
estimates/tasks.
. The Sprint Plan (tasks & hours per Sprint) is
created by the Product Owner &Dev Team – not by

Sprint. It is up to the Product Owner to determine
and ultimately test for viability within the Sprint.
12/6/2006 Page 7
Post-
Implementation
Support
. The PM is responsible for ensuring that post-
installation support is available to the product
recipient.
. A “stabilizing Sprint” may be planned for in the
Release Plan and executed where appropriate.
Team Meetings

Steering
Committee Status
Meetings
. For high-visibility, high-risk endeavors, the PM will
set up and participate in regularly scheduled Steering
Committee Meetings (as per the Communication
Plan) at which the status of the project is discussed.
. The author could find no mention of Steering
Committee Meetings with respect to Scrum.
Team Meetings . As per the Communictaion Plan, the PM will usually
schedule regular team meetings to discuss progress,
actuals/estimates, issues, and risk. Such meetings
may last an hour or more.
. In Scrum, the 15-minute daily Scrum meeting is the
key vehicle for discussing progress, roadblocks, and
upcoming commitments as well as obstacles.
Post-

especially if the transition is fairly sudden. The traditional Project Manager may be compared with the captain
of a ship who is chartered with steering the course, anticipating and overcoming difficulties, and ultimately
safely delivering the cargo and passengers on schedule. In contrast, the Scrum Master acts mainly as an enabler
to the Scrum Team since the entire team is responsible for the outcome of each Sprint. Whereas the Scrum
Master primarily utilizes facilitation skills during the course of a Sprint, facilitation is a subset of the entire skill
set required to be a successful PM. Experience and knowledge regarding requirements definition, time
management, estimating, negotiating, budget oversight, and anticipating risk are all expected of the seasoned
Project Manager. How these attributes may be best leveraged in Scrum - if at all - and to what extent the Scrum
Master is free to tap into them is yet to be determined.

Two final questions to pronder:

1 - Will the definition of Scrum Master evolve over the next decade to incorporate more traditional project
management skills and approaches?
Only time will tell, and the answer may depend upon how Scrum is adapted with regard to a company’s specific
culture.

2 - Will seasoned Project Managers who become Scrum Master find themselves underutilized?
If so, they will probably write a white paper as this author did.

Anne Loeser can be reached at