Abstract
Scrum is one of the agile methodologies designed to guide teams in the iterative and incremental delivery of a product. Often referred to as “an agile project management framework,” its focus is on the use of an empirical process that allows teams to respond rapidly, efficiently, and effectively to change. Traditional project management methods fix requirements in an effort to control time and cost; Scrum on the other hand, fixes time and cost in an effort to control requirements. This is done using time boxes, collaborative ceremonies, a prioritized product backlog, and frequent feedback cycles. The involvement of the business throughout the project is critical as Scrum relies heavily on the collaboration between the team and the customer or customer representative to create the right product in a lean fashion. This paper provides an overview of Scrum and its use in project management.
What is Scrum?
We should first be clear on what Scrum is not. There is a common misconception that Agile is Scrum. While Scrum is indeed agile, it is not the sole method of implementing agile principles. Scrum is simply one of many agile approaches to product development. Other methods include Extreme Programming (XP), Crystal, Feature Driven Development, DSDM Atern, and so on. All of these methods adhere to the Agile Manifesto and its associated principles. A helpful metaphor would be to think of Agile as being ice cream, while Scrum, XP, Crystal, etc., are all simply different flavors, like chocolate, strawberry, vanilla. They are all agile, they are all good, and many can be used in combination.
Simply put, Scrum is an agile method of iterative and incremental product delivery that uses frequent feedback and collaborative decision making.
History
Scrum is based on a 1986 paper written by Hirotaka Takeuchi and Ikujiro Nonaka for the Harvard Business Review titled “The New New Product Development Game.” In this paper, the authors used the sport of rugby as a metaphor to describe the benefits of self-organizing teams in innovative product development and delivery. Jeff Sutherland, Ken Schwaber, and Mike Beedle took the ideas from this paper, including the metaphor, and applied it to their field of software development. They called their new method Scrum, after the rugby term that describes how teams form a circle and go for the ball to get it back into play again. They first applied this method at Easel Corporation in 1993. Schwaber and Beedle wrote about their experiences in their book Agile Software Development with Scrum in 2002, followed by Schwaber's book Agile Project Management with Scrum in 2004, which included the work Schwaber had done with Primavera.
The Scrum Framework
Schwaber refers to Scrum as a framework and not a methodology. This is primarily due to the connotations around the word methodology, which many infer as prescriptive in nature. By contrast, Scrum simply provides a structure for delivery, but does not tell you how to do specific practices, leaving that to the team to determine. Exhibit 1 shows the basic Scrum framework.
Exhibit 1. The Original Scrum Framework
The project begins with a clear vision provided by the business, and a set of product features in order of importance. These features are part of the product backlog, which is maintained by the customer or customer representative referred to as the Product Owner. A time box commonly referred to as an iteration or sprint, is the set amount of time that the team has to complete the features selected. Sprints are generally from one to four weeks in length, and that length is maintained throughout the life of the project so as to establish a cadence. The team selects items from the product backlog that it believes can be completed in the sprint, and creates a sprint backlog consisting of the features and tasks as part of the sprint-planning meeting.
Once the team has committed to a sprint backlog, the task work begins. During this time in the sprint, the team is protected from interruptions and allowed to focus on meeting the sprint goal. No changes to the sprint backlog are allowed; however, the product backlog can be changed in preparation for the next sprint.
During the sprint, the team checks in daily with each other in the form of a 15-minute meeting known as a scrum. The team stands in a circle and each member states what they did yesterday, what they plan to do today, and what is getting in their way.
At the end of the sprint, the team demos the work they have completed to the stakeholders and gathers feedback that will affect what they work on in the next sprint. They also hold a retrospective to learn how to improve. This meeting is critical, as its focus is on the three pillars of Scrum: transparency, inspection, and adaptation.
Roles and Responsibilities
There are only three roles in Scrum: the ScrumMaster, the Product Owner, and the Team.
The ScrumMaster is the keeper of the process, the advocate for the team, and the protector of the team. They remove obstacles, facilitate team communication, mediate discussions within the team and negotiate with those external to the team. Above all, they exist in service to the team.
The Product Owner represents the voice of the customer and has the authority to make decisions about the product. This person owns the product backlog and is responsible for communicating the vision to the team, and defining and prioritizing backlog items. The Product Owner works with the team on a daily basis to answer questions and provide product guidance.
The Team consists of seven plus or minus two people who are jointly responsible for the delivery of the product. They own the estimates, make task commitments, and report daily status to each other in the daily scrum. They are self-organizing, meaning that structure appears without explicit intervention from the outside. In other words, the team owns how it chooses to build product features—the team owns the “how,” while the Product Owner owns the “what.”
The Application of Scrum
Scrum is applied by following a set of ceremonies, or meetings. Required Scrum ceremonies include the sprint planning meeting, the daily scrum, the sprint review and the sprint retrospective. Working in time boxes called sprints is also required. Release planning meetings are optional and allow for the planning and forecasting of groups of sprints.
Sprint Planning Meeting
The sprint-planning meeting is held on the first day of every sprint. The ScrumMaster, Product Owner, and Team are all in attendance. The Product Owner presents the set of features he or she would like to see completed in the sprint (the “what”) then the team determines the tasks needed to implement these features (the “how”). Work estimates are reviewed to see if the team has the time to complete all the features requested in the sprint. If so, the team commits to the sprint. If not, the lower priority features go back into the product backlog, until the workload for the sprint is small enough to obtain the team's commitment.
Tracking Progress
Once the sprint-planning meeting is complete and the team has made a commitment, the team begins to track its progress using highly visible information radiators. These radiators include the burndown chart and the task board.
The task board is used by the team to track the progress of the tasks for each feature. The minimum columns used are To Do, Doing, and Done. Teams will have their daily scrum meeting at the task board, and move items across the board when stating what they did yesterday, what they plan to do today, and what obstacles they are grappling with. See Exhibit 2 for an example task board for a software development project.
Exhibit 2. Scrum Task Board Example (Graphic courtesy of Mountain Goat Software. All rights reserved.)
The burndown chart shows the trend line of the amount of work left to do in the sprint. The x-axis is the number of days in the sprint, and the y-axis is the number of hours for all the tasks that were defined in the sprint-planning meeting. Over the days of the sprint, the line indicating the amount of work left to do should trend down to zero by the last day of the sprint. See Exhibit 3 for a sprint burndown chart example.
Exhibit 3. Sprint Burndown Chart Example
Sprint progress is tracked using the burndown chart, the task board, and the daily scrum. In combination, these three things can provide a clear picture of what's being worked on, what's completed, what's still to be done, whether or not it will be completed in time, and what might be preventing the team from meeting its sprint and/or release goal.
Sprint Review
At the end of the sprint, the team invites stakeholders to a sprint review meeting where the features that were completed in the sprint are demo'd and feedback is requested. The Product Owner keeps track of the feedback and incorporates it as needed into the product backlog.
Once the review is complete, the team (without the stakeholders) conducts a retrospective to determine what they did well that they wish to continue doing, what they struggled with, and what recommendations they have for change going forward. An action plan is created and these items are implemented over the course of the next sprint, and reviewed for efficacy in the next sprint retrospective.
Release Planning
Release Planning is also part of Scrum, and is a way to do long-term planning for a time box that consists of multiple sprints. This is often done quarterly, and the results of the quarter do not have to be a release to the customer, but may simply be an internal release to confirm system integration and validation. Exhibit 4 shows how release planning fits in with the rest of the Scrum framework.
The entire team attends the release-planning meeting, where the Product Owner presents the features she/he would like to see completed in the quarter. The team does not task out these features however, but instead provides gross level estimates to determine what features can be done in what sprint, and how many of these features can be completed by the end of the quarter. Release planning can be feature-driven (how many sprints will it take to complete this set of features?), time-driven (how many features can we expect to have completed by this deadline?) or cost-driven (given this budget, what does our schedule look like and what features will we have done before we run out of money?).
Exhibit 4. Release Planning in Scrum
Some Scrum Examples
Scrum is common in software development projects and myriad examples can be found through simple Google research. What is less obvious is the use of Scrum in non-software projects, so a few of these examples are cited in the following.
Writing a Book Using Scrum
My colleague Stacia Viscardi and I used Scrum to manage our book project. Our product backlog consisted of the chapters we wanted to write for The Software Project Manager's Bridge to Agility, in priority order based on client inquiries. For example, because we seemed to get a lot of questions about scope management and very few regarding procurement, the chapter on scope was at the top of the backlog, while the procurement chapter was near the bottom.
We held a release-planning meeting and moved the backlog items onto flip chart pages that represented our sprints, which were one month in length. At the beginning of each sprint, we held a call to talk about the chapters we would be writing, set goals and expectations, and commit. During the sprint, we checked in with each other several times a week. As we completed chapters in the sprint we would exchange them to get feedback, and then incorporate that feedback into the final copy. Our sprint reviews consisted of a final review of the chapters, and any additional changes ended up in the product backlog to be planned in the next sprint.
As it was just the two of us, we rotated roles and responsibilities. For one section of the book, I was dubbed the Product Owner, and I had final feature authority. For other sections, Stacia had this role. Our ScrumMaster was our editor, even though he did not realize it. He still performed the ScrumMaster responsibilities, however, he reminded us of our deadlines, removed obstacles for us, and gave us the assistance and tools we needed to do our jobs.
And it's not just us using Scrum to write books. Lonely Planet uses Scrum in their travel guide development, “Prior to Scrum, the development of a book was very sequential and required many handoffs and took a long a time to get a book out from conception to publication. Now they involve all players needed to put a book together (writers, graphic artists, desktop publishing, marketing, editors etc) and incrementally develop the book chapter by chapter following the Scrum framework” (Scrum for Non-Software Projects, 2010).
Using Scrum in a Venture Capital Company
Jeff Sutherland is a Senior Advisor at Openview Venture Partners, a venture capital company based in Boston, MA. In 2010, he wrote a paper for the Hawaii International Conference on Systems Science titled Organizational Transformation with Scrum: How a Venture Capital Group Gets Twice as Much Done With Half the Work that describes how Openview uses Scrum in the management of its portfolio.
Openview teams use Scrum in projects “in management, sales, marketing, finance, and customer support for portfolio companies,” as well as pushing Scrum out to their portfolio companies (Sutherland, 2010, p. 1). In one example of Scrum use, the Labs team use one-week sprints to execute operational value-add projects for their portfolio companies, perform due diligence, and institutionalize their value-add capabilities.
When the Labs team initially implemented Scrum, the increased visibility into projects underway made them realize that several of the projects were actually low-value. As a result, they cut 30 percent of their projects, which made room for more high-value projects and allowed them to focus on and finish these projects. In fact, this clarity of focus and the limit of the amount of work in progress in a sprint helped the team to become more productive, as projects no longer dragged out over long periods of time because too many were being worked simultaneously. The team has already doubled their productivity and is “on their way to the second doubling of productivity” as they continue to adapt (Sutherland, 2010, p. 8).
Scrum in Church
Rev. Arline Sutherland works as an interim pastor for the Unitarian Universalist church. She is also the wife of Jeff Sutherland, one of the co-creators of Scrum. In a 2009 paper for the Agile2009 Conference titled Scrum in Church: Saving the World One Team at a Time, Rev. Sutherland described her experiences using Scrum in churches in Massachusetts, Connecticut, Florida, Delaware, and Virginia.
Scrum is primarily used by office staff and volunteers to both “keep the engine running” and in “new initiatives” (Sutherland, 2009, p. 3). Projects under various programming areas such as pastoral care, children and youth, membership development, social justice, music, facilities, finances and fund raising were managed using Scrum.
Several adaptations were made in each instance to accommodate the needs of the team members and the constraints of their environment. For example, it was impossible to hold daily in-person stand-ups with more than half the team holding down day jobs. So Skype was used since “the largest demographic using Skype are grandparents, (and) even older less technologically sophisticated members are often skilled users” (Sutherland, 2009, p.4).
It is worth noting that Sutherland discovered “that each and every time Scrum is introduced into a system it has to be adapted” (Sutherland, 2009, p. 4). Originally discouraged that her implementations of Scrum never seemed to match the ideal of “real Scrum,” she quickly realized that the benefits of genuine adaptive change included the adaptation of Scrum itself.
What Happened To…?
Because this is only a short overview of Scrum, it is expected that the reader may leave with several unanswered questions. In this section, we will look at the top three questions most often asked by those new to agile and Scrum, then leave you with some final words on where to find more information.
What Happened to Gantt Charts and Other Documentation?
Gantt charts are not typically used on Scrum projects. Burndown charts (both sprint burndowns and release burndowns), task boards, backlogs, sprint plans, release plans, and other metrics charts are used instead to communicate progress, status, and forecasts. A variety of agile project management tools exist to provide this type of dashboard reporting, including plug-ins for Microsoft Project.
The only artifacts Scrum requires are the product backlog, sprint backlog, release burndown, and sprint burndown. All other forms of documentation are left up to the team to decide. The agile rule of thumb is that if the artifact adds value and the customer is willing to pay for it, then the artifact should be created. Artifacts created because “it's on the checklist” or “we’ve always done this” are items that should be considered for elimination. Documents required for governance issues (audits, accounting, etc.) must still be created, but often can be streamlined.
What Happened to the Project Manager?
The project manager often becomes the ScrumMaster. This is not always the case and there are many different transformation permutations. For example, a project manager who has been serving as a domain or subject matter expert might be better positioned as the Product Owner. Or a project manager heading up a team of 50+ people may remain in that role and focus on overall project tasks such as procurement and contract negotiation, while the Scrum teams on the project (remember, a Scrum team is 7 +/- 2 people, so a 50-person project will be made up of 6-10 Scrum teams) each have their own ScrumMaster. In this scenario the project manager assists the ScrumMasters in coordinating, strategizing, and removing roadblocks.
What Happened to Using Detailed Tasks and Task Estimates to Generate Projections?
Traditional estimating and planning uses a bottom-up method, where all requirements must be fully defined, with tasks then created and estimated based on this fixed scope. Agile estimating and planning instead uses a top-down method to forecast. Gross level estimating at the feature level is often done using a technique called planning poker, with estimates given in points using the Fibonacci sequence. Teams determine their velocity in points, i.e. how many points on average can the team complete in a sprint. Cost per point is determined by calculating the loaded salaries of the team for period x, then dividing that by the number of points completed in period x. Once you have your team's average velocity and a gross-estimated product backlog, you can forecast project milestones and completion dates, as well as the cost per point and thus forecast project cost.
One paragraph cannot do this topic justice, as entire books have been written on this topic. An excellent book with practical advice on how to do estimating using planning poker and forecasting using velocity and points is Agile Estimating and Planning by Mike Cohn.
Final Words
Scrum is an agile project management framework that helps teams to deliver valued products iteratively and incrementally, while continually inspecting and adapting the process. Project Management Institute members will find they can implement Scrum and still be in keeping with the A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition, as both advocate a plan-do-check-act approach to project management.
This was a short overview of Scrum, and as such did not address many additional areas of interest such as product roadmaps, estimating using points, user stories, story maps, and so forth. These agile practices are often used in conjunction with Scrum, as are other methodologies, such as Kanban and XP. Additional resources on these topics are available online, many for free. A comprehensive reading list can be found at http://www.scrumsense.com/resources/books for those interested in more in depth learning.
