Printer Friendly

Scrum: a tool from the software world can improve analytical project outcomes.


When jurisdictions undertake analytical work such as audits, budget analysis, program evaluation, and special studies, they need to consider the project management tools available and identify the approach that is most likely to be successful. Successful project management can mean stakeholders get exactly what they hoped for, on time, and for the planned cost, while poor project management can lead to a nightmare of unmet expectations, long delays, and cost overruns. A new approach to analytical project management can drive achievement and minimize disappointing and costly results. Applying a software development project management tool--and tailoring it to fit--allows governments to transform the way we get analytical business done.

Scrum is a project management approach that is widely used in the software development industry, and it has recently begun to expand beyond the borders of the technology world. When traditional project management was used in software development, it was often unable to effectively manage the complexities, ambiguity, and rapidly changing environment software developers faced. A new set of software development approaches was created, including Scram. Since many government analytical projects face similar complexities, ambiguities, and changing environments, Scrum can be a useful project management tool for the public sector, as well.



In the term's original use, a scrum is a rugby formation where players work as a team to get possession of the ball. Scrum projects emulate rugby teams, with team members working collaboratively on a common goal. In contrast, traditional project management can be envisioned as a relay race, where players pass a baton in sequential phases of handing off work.

Under the traditional approach (see the left triangle in Exhibit 1), there is a set scope that allows the schedule and necessary resources to be estimated. However, the resources and schedules of many government analytical projects are fixed, as shown in the triangle on the right. The element to estimate is how much scope can be addressed, given those constraints. In other words, under traditional project management, the plan drives cost and schedule estimates. In Scrum, the project vision and desired value drive estimates of scope.


Government analytical projects need to be focused and efficient. The Scrum approach delivers business value incrementally, with the highest priority elements delivered first. Scrum employs a continuous feedback loop to ensure that the expected value of the project is realized, while incorporating emerging requirements of the ever-changing government environment. The Scrum approach allows decision makers to end the project when it makes sense to do so, while still realizing the bulk of the value.

Scrum can increase project efficiency and staff productivity in a number of ways. Work activities and requirements are very explicit in Scrum, reducing the amount of time spent eliminating ambiguity around expectations. Teams are self-organizing, and they are empowered to estimate how long it will take them to complete tasks and to control how much work they commit to during each iteration of a project. The resulting ownership drives accountability.


Government is full of uncertainty and complexity. Some project environments (e.g., budget changes, political priority adjustments, or the emergence of unexpected obstacles) can derail a project that relies heavily on front-end planning. Scrum can be a good fit because it thrives in multifaceted, ambiguous, and shifting environments. The approach relies on a system of progressive elaboration; embracing change.


Scrum practitioners use specific terminology. Using the specific Scrum terms may feel stilted at first, but the act of using this new terminology helps create a mental and operational shift in one's approach to project management. Exhibit 2 identifies key Scrum roles, tools, and processes that work together to become a Scram practice.

The roles in Scrum are important in their responsibilities as well as their boundaries. ScrumMasters help the Scrum team give its best performance. ScrumMasters do not direct or assign tasks; instead, they focus the team and help resolve barriers to completing their commitments. The product owner articulates the vision for the project and communicates the value project outputs must embody. The Scrum team is self-organizing, and any team member may take on any task. The team determines how much work it can commit to completing in a given sprint--a regular, repeatable work cycle of one to four weeks. The product owners are the stakeholders who drive the project's goals. The team's manager is a product owner, and the role can also consider the perspectives of other interested parties such as elected officials, the public, or others who have an interest in the project. The product owner identifies the destination on the map, the team determines how they will get there and drives the car, and the ScrumMaster makes sure that they have enough gas and road snacks, and handles any mechanical problems along the way.

Exhibit 3 depicts the basic Scrum process and how Scrum processes and tools fit together. The stack of boxes on the far left is called a product backlog. The product backlog is a prioritized list of work needed to accomplish all the goals and priorities associated with a project. The product backlog is constantly reprioritized, and items can be added or eliminated as the project moves forward. The smaller stack next to the product backlog is the sprint backlog. During sprint planning, the sprint backlog is selected from the highest-priority elements of the product backlog and expanded into specific tasks. This is a to-do list for a sprint.

The heart of Scrum is the sprint process, which is depicted by the larger cycle in Exhibit 3. Each Scrum project consists of a series equal-length sprints. The purpose of each sprint is to produce a fully formed, potentially shippable product, represented by the box on the right side. The smaller cycle is the daily Scrum, a daily meeting held to coordinate work, identify barriers, and help communicate the team's progress on the sprint backlog tasks to one another.

At the end of each sprint the team holds two meetings, the sprint review and the sprint retrospective. The sprint review is an informal meeting where the Scrum team demonstrates the shippable product for the product owner, verifying that the anticipated product benefits have been realized. Information from this meeting is then used to reassess the product backlog contents and prioritization. The sprint retrospective is the opportunity for the Scrum team and the ScrumMaster to inspect the sprint process and develop approaches to improve the next sprint cycle.



A core concept of Scrum is its approach to project planning and execution: Is it better to plan a project and then execute it, or plan while the project is being executed? Fully planning activities at the outset might make sense for some projects; however, this approach can lead to a period of significant disruption when changes do occur. In analytical work, information is frequently uncovered during the course of the work that changes the way the project should proceed. For example, discovering a major internal control weakness during a program review would lead a team to look more carefully at that area than they might have originally planned.

An alternative to the plan-then-execute model for government analytical projects is the progressive elaboration approach espoused in Scrum. This model includes some general planning as the project moves forward, identifying key areas of work--the "what." The Scrum team repeatedly cycles back to planning during their execution, adding detail and new insights to the "what." At the same time, the team regularly breaks each project element into the tasks needed to accomplish it, the "how."

In Scrum, change is a built-in part of the process. It is seen as an opportunity to improve each iteration of planning and implementation with new information and an accurate reflection of the current environment and needs. This flexibility is seen as regular and appropriate project recalibration.


To ensure the ultimate quality and usability of the project output, Scrum has adopted a process that creates "user stories." User stories describe the value of each piece of a project from stakeholders' perspectives. In government, there is always a series of internal and external users. Users can include elected officials, government managers, managers inside the project's organization, employees who will be users of the deliverables, or the public.

The outline for a user story is "As a <user/stakeholder> I want <goal> so that <value>." In each story, the team should work with stakeholders to define the specific person or group with interest in the project and the desired characteristics of the project outcome that are important to that user, and describe what value they would derive from those goals. For example, some user stories for a program evaluation might include:

* As a taxpayer I want an efficient program so that my tax dollars are well spent.

* As a manager I want acknowledgement of our positive practices so that the report is balanced.

* As a councilmember, I want full description of the cause of any problems so that I can use legislative authority to resolve them.

Using these stories will help ensure that the project is consistently guided by the qualities varying stakeholders demand. As in most cases with a variety of interested parties, some of these stories may not lead the project toward the same end. For example, in the case of the hypothetical evaluation, the manager might prefer to resolve problems out of the public eye, whereas the public might want full transparency. These competing interests should be weighed in the context of the project's guiding laws or standards and other aspects of the environment, and prioritized accordingly.


When project outputs such as reports or plans aren't available to stakeholders until the project is finished, a project can move too far off course before corrections can be made. In some cases, the project could wholly miss the mark and need to be redone completely. This wastes resources and generates a good deal of frustration.

The Scrum process requires rethinking the approach to project outputs. At the end of each sprint--the one- to four-week work iteration--a potentially shippable product increment is expected. A potentially shippable product is one that is functional and complete, based on the criteria set forth during planning. For example, if the ultimate project output is an analytical report, the potentially shippable product could be a chapter, a section, or a completed segment of analysis. Or if the final product will be a jurisdiction-wide budget, potentially shippable products might include completed analysis of a segment of the budget, a completed meeting during which budget questions or concerns with management were discussed, or a draft budget document.

Incremental delivery ensures that the product reflects stakeholder requirements, but another key benefit of this approach lies in the usable output increments. There are more risks to bringing a project to completion than ever before, not the least of which is the risk of loss of project funding as a result of the often-painful budget choices being made by all levels of government. When usable product increments are developed, there are two impacts. First, if the project is terminated, the work has still led to some usable outcome. Second, having usable segments of output demonstrates the project's concrete benefits, which can become a rationale for fully implementing the project.


Scram helps an organization put the elements of effective project management into operation. Most of the elements of Scrum aren't revolutionary; it is the way they move together and the accounting for the work that is ground-breaking. The specificity, transparency, and accountability built into Scrum have positive effects on staff productivity and morale.

Overtly breaking out each work element into the specific tasks needed to complete it drives the project forward. This precision, together with daily coordination, identification of barriers, and communication of progress, helps individuals and teams manage their workflow.

The brief daily project meeting builds on the specific work tasks to create transparency and accountability. The Scrum team answers only these three questions at this 15-minute meeting, called a daily Scrum:

1. What did you do yesterday?

2. What will you do today?

3. Are there any impediments to completing the tasks to which you've committed?

Instead of going several days, or even weeks, before barriers are identified or procrastination is confronted, the team moves quickly through the tasks, promptly identifying impediments and using accountability as a motivating force.

The team's ScrumMaster is responsible for resolving barriers to task completion. The very existence of this role facilitates productivity. The ScrumMaster's sole duty is to make it as easy as possible for the team to complete its work. The goal is to keep the team working on the critical elements of the project while the ScrumMaster performs tasks such as obtaining information from external sources that the team needs, heading off external demands on team members, or even bringing coffee to the team.

A final Scrum process that makes use of efficiency and productivity is the sprint retrospective. At the end of each sprint, the team comes together and reviews the sprint. It identifies what went well, what could have been better, and what changes will be implemented in the coming sprints. This frequent, cyclical identification of lessons learned allows the team to quickly improve its process and outputs.


Scrum will not solve pre-existing organizational problems; in fact, it is likely to magnify them. If there is a lack of communication and collaboration within work teams, Scrum could fail. If key project stakeholders are typically not involved in or open to providing regular direction, Scrum teams might not have sufficient guidance. Poor performers will remain poor performers, and Scrum's team accountability will bring insufficient work efforts to the forefront.

Sometimes the characteristics of a project team aren't ideal for a successful Scrum implementation. For instance, a project with relatively inexperienced staff isn't ideal because teams must be able to work fairly autonomously during work iterations. If members of work teams do not typically have the authority to make decisions related to completing project work, this can also lead to Scrum failures.


Processes that are fixed and linear may not be the best application of the Scrum approach. For example, regular financial audits with sequential steps don't require regular reprioritization and evaluation. Projects that are regular and repeated may function more effectively using other project management approaches.

In any situation where Scram is applied, work must be done to ensure that the approach meshes with pre-existing processes or procedures. A little bit of real-world common sense goes a long way in the implementation of Scrum outside of the IT realm. Making some adjustments to the framework can mean the difference between success and failure in each unique environment. At the same time, watering down Scrum too much will reduce its value.


Fully implementing Scrum can create remarkable project success, especially in complex, dynamic environments. The Scrum structure and processes work together to ensure that the project delivers project benefits in a timely, efficient way. Scrum provides a framework project teams can use to employ key project management elements such as planning, methodology, risk management, internal and external communication, time management, and output development. Scrum provides an effective and even fun way to achieve success with analytical projects.

Learning More about Scrum

Several books and Web sites dedicated to the practice of Scrum can provide further guidance for using the strategy. Examples include Ken Schwaber's Agile Project Management with Serum (2004, Microsoft Press) and the Scrum Alliance at

KYMBER WALTMUNSON, MPA, CIA, is principal management auditor at the King County Auditors Office in Seattle, Washington. She is also a consultant at Waltmunson Performance Consulting and a member of the board of directors for the Association of Local Government Auditors and the Washington State Local Government Auditors Association.
Exhibit 2: Key Scrum Roles, Tools, and Processes

Scrum Roles     Scrum Tools           Scrum Processes

ScrumMaster     Shipppable Product    Sprint Planning
Scrum Team      Product Backlog       Daily Scrum
Product Owner   Sprint Backlog        Sprint Review
                                      Sprint Retrospective
COPYRIGHT 2011 Government Finance Officers Association
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2011 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Waltmunson, Kymber
Publication:Government Finance Review
Date:Aug 1, 2011
Previous Article:Improve performance using the GFOA'S new financial management assessment tool.
Next Article:Bringing numbers to the table: what finance officers need to know about collective bargaining.

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters