1. A Brief Introduction to the SCRUM Agile Methodology
Taha Kass-Hout and John Page, Thursday December 20, 2012
The aim of this paper is to provide a brief overview of the SCRUM Agile Methodology, and to
give organizations an idea of how SCRUM may affect the traditional development of
requirements and deliverables.
SCRUM in a Nutshell
Studies by the Harvard Business School, Forrester research, Digital Focus, and similar
organizations have shown that in comparison to traditional methodologies, agile development
can consistently reduce cost and schedule overruns, defect rates, time to deployment, and
rejection by end users.Although there are several competing Agile Methodologies, SCRUM is
the most effective in managing complex development and integration tasks. SCRUM is highly
structured, yet tries to minimize overhead, is based on process control theory, and its key
elements are summarized below. It differs from other methodologies in that is has a strong
emphasis on performance monitoring and accountability, and it provides a strong emphasis on
delivering usable increments of functionality to end users as quickly as possible. The use of
SCRUM is not only limited to software development—it is very effective in removing “analysis
paralysis” in requirements specification and design efforts as well. The keys to SCRUM are the
subdivision of work (both full programs and even quarterly release cycles) into two- to four-
week units called a sprint, each one of which has specific success criteria defined for it, and the
transparent management of requirements in a backlog.
Anatomy of a SCRUM Development Effort
Element Description
Roles Product Owner: Primarily responsible for determining which requirements in a project
backlog will be addressed in a given sprint and determining acceptance of the results of each
sprint.
SCRUM Master: The SCRUM Master is responsible for facilitating the development for
each sprint, removing obstacles, managing risks, and communication paths.
Team A SCRUM team is a multi-disciplinary team. It consists of a development team and a larger
group of stakeholders, potential end users, and domain experts.
Time Each two- to four-week sprint is started with a Sprint Planning Meeting, where
Boxes outstanding requirements in the product backlog are prioritized and a subset of them
is selected to be incorporated into the Sprint Backlog.
A Daily Scrum is a daily standup conducted by the SCRUM Master with the
development team to determine which requirements have been addressed and to
identify any major risks or obstacles. This is strictly limited to 10-15 minutes, and
longer discussions are taken off line. This provides a tremendous ability to identify
risks and obstacles early.
A Sprint Review is held at the completion of the sprint, where the Product Owner
determines acceptance of the complete requirement items and a lessons-learned
review is held.
A series of sprints may be bookended by a Release Planning Meeting and a Release

2. Review Meeting in order to coordinate efforts over a longer period of time. Releases
are typically 3, and never more than 6 months apart.
Artifacts SCRUM has very few artifacts, but all are used. Transparency and on-demand access to
SCRUM artifacts is essential. Artifacts are provided as part of a project portal or wiki, where
access is provided to the project requirements backlog, the sprint requirements backlog,
meeting minutes, action items, issues lists, and burndown charts for both the project and
sprint. Burndown charts help to capture the velocity of an effort, and SCRUM teams are
capable of making very accurate resource and schedule estimates after a few sprints.
Rules The rules in SCRUM are in place to reduce the amount of overhead effort that needs to be
invested. The roles of the Program Owner and the SCRUM Master are defined to maximize
productivity of the development team while keeping the stakeholders engaged. Daily
SCRUMs are limited to progress and issue reporting and are not to take more than 15
minutes.
Applying SCRUM to the Development and Tracking of Requirements:
One of the greatest causes of failed software projects is the myth of a “complete” set of
requirements. Not only do needs change during the course of a development effort, but typically
the need for many requirements is not felt under development is underway. No amount of peer
review can unearth all of the specific requirements that are encountered in the course of
development. In contracts, it is often difficult to change requirements, and a finished system,
even though it meets the requirements on paper, is often rejected by end users, whose first view
of the finished system is at the go-live date.
The SCRUM Agile Methodology does not assume a “complete” of requirements at the onset, but
rather managers a dynamic backlog of requirements. The Development team is part of a
SCRUM team that provides stakeholder input, and is responsible for accepting the output of each
“Sprint”
User Stories support high-level definitions of requirements and capabilities focusing on
capturing value to end users and are only developed as far as needed to develop resource
and schedule estimates through a technique called story point analysis. User stories are
optimized to best support the level of detail needed for prioritization and planning efforts
in conjunction with the SCRUM Team. During the course of the development process,
selected user stories are decomposed into more specific types of requirements, such as
Use Cases or specific textual requirements.
Frequent Releases: A usable amount of functionality should be released to end users
every three months, and no longer than 6 months. The VA has found that allowing more
than 6 months before a release was the major cause of many of their failed projects.
Backlogs are collections of unfulfilled requirements. The requirements backlog will
identify capabilities that either have not yet been assigned to a task order or represent
common needs across multiple task orders. Each task order will support a backlog of
specific requirements, which in turn are decomposed to populate the backlog for a given
release (typically a three-month development cycle) and then further into “sprints”, which
are two- to four-week development increments. The addition, modification, and

3. prioritization of backlog elements is done transparently with the involvement of a
SCRUM Team.
Burndown and Velocity measures are collected to provide measures of the team’s
progress against the requirements. The satisfaction of requirements is eventually traced
down to a daily level. Collected performance metrics associate the time and resources
needed to address both the burndown rate (the relative degree to which the requirements
in a given backlog are completed over time), as well as the “velocity”, which measures
the team’s ability to ingest future requirements. Velocity calculations allow a team to
“calibrate” its abilities quickly and make reliable estimates for future development.
Sample SCRUM Task List: Public Health Platform
The challenge to an organization new to agile development is to learn to break apart the problem,
and identify manageable portions early, as well as to prioritize different sets of requirements.
Unlike the traditional waterfall cycles, there is always an opportunity at every 2-4 weeks to
revisit and re-prioritize requirements.
The SCRUM Approach to Deliverables
Another major difference in SCRUM is that there is far more transparency in the production of
deliverables. In a typical waterfall-based project, deliverables represent a discrete milestone gate
with specific acceptance criteria. While this approach supports the need for milestones and
gates, it still allows for too many surprises too late in the process. Contractors are typically very
reticent to show incomplete artifacts to a client, and often subject them to several layers of
internal review. In SCRUM, on the other hand, the approach is of complete transparency, where
artifacts are shared on a wiki or portal, even in their draft form. Any authorized user may view
them 24/7. While this can be a great culture shock, particularly if a development team is not
used to such a degree of visibility, it greatly reduces the amount of surprises and disconnects on a
project, and allows major problems to be identified much sooner.

4. SCRUM efforts also support more parallelism between requirements specification, design,
development, and deployment, which means that the traditional waterfall artifacts are developed
in parallel as well. The definition of each sprint allows the team to define a series of “mini-
milestones” or acceptance criteria at several points prior to the initial submission of a
deliverable. There is no better way to validate requirements and design than to repeatedly force
them up against the “real world” of a development cycle. The ways in which the SCRUM agile
methodology enhances the tracking of traditional artifacts is illustrated here.
Burndown and Velocity:
Development teams using the SCRUM Agile Methodology estimate the complexity of each user
story they implement, and then compare them to the resource “burn” rates user to implement
them. After a few sprint cycles, a team becomes well enough calibrated that it can make
accurate estimates, as well as modeling “what if” scenarios if changes are to be made to baseline
features of the systems. This allows the SCRUM team to make informed decisions, should there
be a need to address an emerging need, and timely warning if initial assumptions had
underestimated the complexity of the problem.