A Brief Introduction to the SCRUM Agile Methodology
A Brief Introduction to the SCRUM Agile MethodologyTaha Kass-Hout and John Page, Thursday December 20, 2012The aim of this paper is to provide a brief overview of the SCRUM Agile Methodology, and togive organizations an idea of how SCRUM may affect the traditional development ofrequirements and deliverables.SCRUM in a NutshellStudies by the Harvard Business School, Forrester research, Digital Focus, and similarorganizations have shown that in comparison to traditional methodologies, agile developmentcan consistently reduce cost and schedule overruns, defect rates, time to deployment, andrejection by end users.Although there are several competing Agile Methodologies, SCRUM isthe most effective in managing complex development and integration tasks. SCRUM is highlystructured, yet tries to minimize overhead, is based on process control theory, and its keyelements are summarized below. It differs from other methodologies in that is has a strongemphasis on performance monitoring and accountability, and it provides a strong emphasis ondelivering usable increments of functionality to end users as quickly as possible. The use ofSCRUM is not only limited to software development—it is very effective in removing “analysisparalysis” in requirements specification and design efforts as well. The keys to SCRUM are thesubdivision 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 thetransparent management of requirements in a backlog. Anatomy of a SCRUM Development EffortElement DescriptionRoles 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, whereBoxes 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
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 ofrequirements. Not only do needs change during the course of a development effort, but typicallythe need for many requirements is not felt under development is underway. No amount of peerreview can unearth all of the specific requirements that are encountered in the course ofdevelopment. 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 viewof the finished system is at the go-live date.The SCRUM Agile Methodology does not assume a “complete” of requirements at the onset, butrather managers a dynamic backlog of requirements. The Development team is part of aSCRUM 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
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 PlatformThe 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 torevisit and re-prioritize requirements.The SCRUM Approach to DeliverablesAnother major difference in SCRUM is that there is far more transparency in the production ofdeliverables. In a typical waterfall-based project, deliverables represent a discrete milestone gatewith specific acceptance criteria. While this approach supports the need for milestones andgates, it still allows for too many surprises too late in the process. Contractors are typically veryreticent to show incomplete artifacts to a client, and often subject them to several layers ofinternal review. In SCRUM, on the other hand, the approach is of complete transparency, whereartifacts are shared on a wiki or portal, even in their draft form. Any authorized user may viewthem 24/7. While this can be a great culture shock, particularly if a development team is notused to such a degree of visibility, it greatly reduces the amount of surprises and disconnects on aproject, and allows major problems to be identified much sooner.
SCRUM efforts also support more parallelism between requirements specification, design,development, and deployment, which means that the traditional waterfall artifacts are developedin 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 adeliverable. There is no better way to validate requirements and design than to repeatedly forcethem up against the “real world” of a development cycle. The ways in which the SCRUM agilemethodology enhances the tracking of traditional artifacts is illustrated here.Burndown and Velocity:Development teams using the SCRUM Agile Methodology estimate the complexity of each userstory they implement, and then compare them to the resource “burn” rates user to implementthem. After a few sprint cycles, a team becomes well enough calibrated that it can makeaccurate estimates, as well as modeling “what if” scenarios if changes are to be made to baselinefeatures of the systems. This allows the SCRUM team to make informed decisions, should therebe a need to address an emerging need, and timely warning if initial assumptions hadunderestimated the complexity of the problem.