The Scrum framework

Developed by Sigrún Sævarsdóttir

This article will focus on the Scrum framework from a project management perspective, even though the topic is also relevant for program and portfolio management. This article aims to describe the Scrum framework and its application in a simple way, where figures are used to support the understanding. It is aimed at readers interested in knowing the basics of the Scrum framework as well as beginners using Scrum. The annotated bibliography gives some good example for further knowledge as for example Ken Schwaber's book Agile Project Management with Scrum[1]. Furthermore it is highly recommended to take a look at scrum.org[2] where a lot of material and videos on the topic have been gathered.

The article will zoom in on how the Scrum framework relates to the project and development life cycles presented in the PMI standards. Where it will be compared to the Waterfall model[3], as that model can be considered the most traditional project management model . Furthermore benefits and limitations of the Scrum framework will be addressed from for example a risk management and customer involvement perspective.

Abstract

In the complex technology and business world we live in today, there is a need for flexible project management practices. Agile Project Management addresses that by being more flexible, moving faster and being more responsive to customer needs than traditional approaches . In addition companies are facing growing pressure in delivering products quickly to the market. With this added pressure the risk of failure increases. In cases where there is high complexity it can be hard to use traditional predictive approaches where the project deliverables are defined at the beginning of the project and changes to the scope are harder to manage (Page 674). Here it can be challenging for companies to evolve quickly or inexpensively enough when nearing the end of the development lifecycle. In these cases Agile Project Management could be the best option. Agile Project Management is able to respond well to change and customer involvement is high throughout the project. It is clear that Agile practices are becoming more and more popular, there is even a drastic increase of information on Agile or Adaptive Project Management in the 6th edition of the PMBOK Guide[4]. Where in a number of chapters they have included a subsection that addresses Considerations for Adaptive Environments, in addition to that they describe Agile techniques like the sprint and iteration planning (Page 642).

Scrum is an Agile Project Management framework, where projects are managed in short sprints or iterations. These Sprints last up to 30 days. The Scrum framework has a set of roles and events that will be discussed further in this article. In Scrum the control is moved from the traditional central scheduling to the teams itself. Where individuals closer to the actual work take charge of the decision making. With this frameworks the feedback loop between customers and developers is much shorter, the progress is visible, inspections are done constantly and adaptations done when needed (Pages 12, 22). This is especially important in complex projects where companies have to be able to adjust to changes in scope or specifications.

Big idea

In 2001 a group called the The Agile Alliance published the Manifesto for Agile Software Development[5] ". It can be said that this group started an Agile movement. Even though it started as a movement to help software development Agile Project Management is now being used in many other industries and projects. The following bullets are taken from the Agile Manifesto and highlight that people practicing Agile methods value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan ".

However it was in the early 90s when members of the Agile Alliance Ken Schwaber & Jeff Sutherland started developing the Scrum framework (Page 1), with the first publication 1990 in the book Wicked Problems, Righteous Solutions (Page 526). In addition to the values from the Agile Manifesto Scrum also highlights the following values: Commitment, Focus, Openness, Respect and Courage (Page 4). Since 2001 Agile Project Management has grown in popularity and in 2009 more organisation were using Agile than Waterfall processes. From those Agile processes the majority was using the Scrum framework or 84%. In 2009 Ken Schwaber created an organisation Scrum.org [www.scrum.org], reaching a broader audience and providing access to materials and courses. There you can access the Scrum Guide that Ken Schwaber and Jeff Sutherland published in 2010, which gives great overview of the Scrum framework and its application . As previously mentioned this popularity is also reflected in the PMI standards

In the end the ultimate goal is to deliver great customer value, that is what Agile Project Management does by constantly seeking involvement from its customers. Evaluating and validating if what is being made is meeting the set business case . This business case sets the objectives and success criteria for the project. Most often the success or the real benefits of a project can‘t be seen until the project has been done. However one could assume that by having this constant validation, and close relationship with the stakeholder will result in target benefits being met and higher project success rate (Page 547).

It is understandable that you might ask yourself if a document written in 2001 like the Agile Manifesto is still relevant today. When looking at one of its principles stating that The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. This could be often impractical where teams are geographically dispersed. In 2001 when signing the Manifesto it might have been hard to anticipate the progress that would happen in software development as well as in technology overall. Where today there are many platforms that can be used for communication. What has also been the learnings of working in a pandemic where face-to-face communication is limited is that majority of work has been possible through remote work, so in that sense this principle can be challenged. Furthermore it can be considered that customer collaboration has become more complex through the years so the principle of Business people and developers must work together daily throughout the project can be cumbersome .

The Scrum Team

The Scrum Teams works with the Scrum Artifacts which consists of: 
Product Backlog, which emphasises the Product Goal
Sprint Backlog, which emphasises the Sprint Goal
Increment, which emphasises the set of product functionalities developed during each Sprint 

The Scrum Team has three roles: The Scrum Master, Product Owner and the Developers (The Team). It should be mentioned that even though one role is called Developers it does not mean that the Scrum framework is only meant for Software development. It was first developed for that purpose however now used worldwide within various organisations. Scrum Teams are relatively small, and usually consists of 5-9 people. The Scrum Team are the individuals that are considered to be committed to the project, they are called Pigs. However people that are interested in the project, have no accountability or responsibility are called Chickens. There is a clear distinction of authority between these two groups where the Chickens are not able to interfere without having the proper permission and the Scrum team has the full authority to do whatever it takes to make the project a success (Pages 26-28).

• The Product Owner represents the customers of the project. The Product Owner is in charge of making a plan that meets their vision and needs. That is done by setting up a Product Backlog, the Backlog contains both functional and nonfunctional requirements that have to be met to reach the goal or vision. This Backlog gets prioritised, making sure that the Scrum teams starts with the main functionalities. With this prioritisation of functionalities a proposed release plan can be set. It is therefore the role of the Product Owner to priorities and decide what will be done during the sprint. This is then presented to the team during a Sprint planning meeting (Page 26). The Product Owner manages the Backlog, makes sure that the backlog is well organised and the content visible. He is also the only person that can make decisions on adjusting/changing something in the backlog (Page 6).

• Scrum Master makes sure that everyone within the Scrum Team knows the principles of Scrum and makes sure that everyone follows them. Another key role of the Scrum Master is to remove any obstacles that might come their way, ensuring that the team can complete their work. The Scrum Master should be managing the Scrum process, making sure that everyone is on the same page. As Ken Schwaber describes so well by comparing a ScrumMaster to a sheepdog, responsible for keeping the flock together and the wolves away (Pages 26-28,39). The Scrum Master is a role that is often filled by a project manager, however the Scrum Master should not manage or define the work.

• The Developers is a cross functional team, that is self organising and self managing. Where the latter is key as Scrum Teams should not be managed rather they are responsible for managing their own work and making sure that the job gets done during each sprint (Page 26). It could be described as the Developers own how they choose to get the job done in comparison to the Product Owner that owns what should be done

Application: The Scrum Events

Sprint

A Sprint is often said to be the heartbeat of the Scrum framework. It is in the Sprints where all the necessary work is done to achieve the set Product Goal. All Scrum events are time boxed, where a Sprint is usually 30 days or less. When a Sprint ends the next sprint takes over. The following events are linked to a sprint: Sprint Planning meeting, Daily Scrum, Sprint Review and Sprint Retrospective meeting (Page 27). In Figure 1 you can see the sequence of the Scrum events.

Figure 1: The Scrum Events, Adapted from Ken Schwaber's Agile Project Management with Scrum (Figure 1-3)

Sprint Planning meeting

A Sprint Planning meeting may last up to 8 hours when preparing a 30 day Sprint (Page 9). The Product Owner uses the first 4 hours to introduce to the Scrum Team the Product Backlog. He focuses on the highest priorities within the next Sprint and why those are important and bring value to the project (Page 27). From these priorities the Scrum Team assesses and selects what items they estimate they will be able to get done during the Sprint, here it is important to determine what their Definition of Done is. What they estimate to get done is reflected in the Sprint Backlog. Lastly the team evaluates how they will be able to get the work done. Members of the Scrum Team are the only ones that can determine how the items from the Product Backlog are turned into Increments of value (product functionalities), (See Figure 2) By the end of the Sprint Planning meeting a Sprint Goal has to be set (Pages 8-9),.

Figure 2: The three main topics for the Sprint planning meeting, Adapted from the Scrum Guide , available at https://www.scrum.org/resources/scrum-guide

Daily Scrum

Daily Scrum are 15 minute meetings held at the same time and same place each day to track the progress, and how they are doing in regards to the Sprint Goal. During that meeting they also evaluate obstacles that are preventing them from getting the work done (Page 28). To track the progress the Scrum Team often uses visual boards called Scrum Boards (See Figure 3) that they update during the meetings. Where the minimum categories would be: to do, doing (in process) and done. The items from the Sprint Backlog are evaluated and divided into manageable blocks, called stories (Figure 3), the stories are then divided into subtasks . During the Daily Scrum meeting the Scrum Team moves the tasks around on the visual board according to the progress. Another way of visualising how much of the work is done during each Sprint is by the use of Burndown charts[6]. Burndown charts provide good overview of the progress, for example when looking at Figure 4 the correlation between time and remaining work for one Sprint lasting from July 7th to August 3rd is shown.

Figure 3: An Example of a Scrum Board, Adapted from the fyi blog; The Top 10 Scrum Boards you should be using by Marie Prokopets , available at https://usefyi.com/scrum-board/

Figure 4: Burndown chart to illustrate Scrum, picture by Manuelmorales (2009), distributed under a Creative Commons Attribution 3.0 Unported license, available at: https://commons.wikimedia.org/wiki/File:Burndown.png

Sprint Review

Sprint Review is a 4 hour meeting that takes place at the end of the Sprint. During that meeting the Team presents to the Product Owner and other relevant Stakeholders the outcome of the work that was done during the Sprint (Page 28). This meeting is informal and stakeholders can give feedback on the work done during the Sprint. During that meeting the features are evaluated and from that new opportunities are explored and what next steps should be (Page 9),.

Sprint Retrospective meeting

The Scrum Master leads the Sprint Retrospective meeting, it is a 3 hour long meeting where the Scrum Master goes over what went well during that Sprint and what could be done better in the next sprint in respect to the Scrum process framework and practices (Page 28). The meeting should ensure that the next Sprint will be more enjoyable, effective and quality is increased . This is also an interactive meeting where not only the Scrum Master does the talking, the team is involved and discusses their opinions on the previous Sprint, what went well and what problems they encountered that were challenging (Page 10).

Scrum vs Traditional Project Management (Waterfall)

The Waterfall Model has a predictive life cycle, where time, cost and the project scope are well defined early on in the life cycle. Where changes have to be managed well (Pages 18-19) and can be costly. The Waterfall projects begin at one place and then similar to a waterfall cascade down to the end of the project in a forward direction.

Scrum has an adaptive life cycle that is agile, where a scope is defined and approved before the start of each sprint. Adaptive life cycles are also often called change-driven life cycles (Pages 18-19). The latter emphasises that Agile methodologies like the Scrum framework welcomes changes. As an iterative model Scrum starts small and then adds on throughout the project. Figure 5. gives an overview of the difference between the project life cycle for Scrum and Waterfall projects.

Figure 5: Project life cycle: Waterfall vs Scrum Adapted from the articleScrum vs Waterfall vs Agile vs Lean vs Kanban bu Visual Paradigm accessible at:https://www.visual-paradigm.com/scrum/scrum-vs-waterfall-vs-agile-vs-lean-vs-

For each project the project management needs to consider what approach fits best. For that purpose the following table will give a short overview of the differences between the Scrum framework and the Waterfall model.

Scrum vs Traditional approaches (Waterfall)

	Scrum	Traditional (Waterfall)
Planning	Planning is done based on the sprints and the product backlog, therefore the plans are shorter where there are multiple deliverables	There is a detailed timeline with long term project plans that are done in the beginning of the project.
Reviews	Reviews are being done after each of the Sprints with the relevant stakeholders, therefor they are being done throughout all the project stages (Page 46).	Review is done at the end of the project life cycle
Customer involvement	High customer involvement, The customer is involved all throughout the project	Low customer involvement Customers are often only involved during the beginning and at the end of the project
Ability to adapt to change	Closely linked to the frequent reviews and customer involvement. In the Sprint review meetings where the functional increment is reviewed there is the opportunity to evaluate if any changes are needed or any new ideas come up.	Many resources devoted to change management (Page 46) Changes are more costly and harder to make as projects have been planned ahead.
Requirements	Throughout the project detailed requirements are being made	Before the project start detailed requirements are defined (Page 46).
Product delivery	After each Sprint a product is delivered in a functional state, it is not the finished product. However it shows the product functionality (increment) Done during the sprint	At the end of the timeline the product is delivered, fully functioning according to the requirements set in the beginning .

Unfortunately it is not as easy as following a checklist to evaluate what framework/model to use. Some might say that when dealing with a complex project you should use Agile Project Management methodologies and when tackling small to medium scale projects you should use more traditional Project Management Methodologies like the Waterfall model. However it is not as black and white as that. You could consider that if you have a project that has high degree of change then Agile would be a better fit. There are still quite complex projects that are easy to plan and straight forward where the Waterfall model fits better .

Benefits of Scrum

• It has been said that by using the Scrum framework companies have a faster way to the market. This is beneficial as it was previously mentioned that companies are pressured to bring products fast to the market. There are a number of reasons for why this is the case with Agile Project Management. Firstly because the teams have to deliver increments frequently, meaning that there is better support and more pressure on deliveries. Another reason could be that the Customer might be happy with the product sooner, due to those frequent evaluation by the customer after each sprint. During those the customer is introduced to a functioning product. In the process there might be some functionalities that they had requested in the beginning that aren't as important as before. With a more traditional approach the customer would be reviewing the product at the end of the timeline. In 2008 the QSM Associates concluded in their report "Agile Impact Report, Proven Performance Metrics from the Agile Enterprise" that projects managed with the Agile approach were 37 % faster at delivering their products to the market and 16% more productive .

• The customer is heavily involved throughout the project, validating the functionalities of the product. As introduced in the Big idea chapter this can increase the chances of the customer being satisfied with the end product. For many companies the customer satisfaction is how they measure their project success. Customer satisfaction is also acknowledged by the PMI standards as a factor in the success of a project. Therefore this close relationship between the Scrum Team and the customers can increase the possibility of meeting the target benefits of the project (Page 13).

• When working with complex projects there is a higher risk of uncertainties and risks. Agile Project Management uses frequent reviews that makes it easier to identify and manage risks. By reviewing each Increment the risks for each Sprint can be identified, analysed and managed. The other aspect is that you have a good overview of the job ahead with the overview of the backlog, with this knowledge it is easier to priorities the progresses according the the risk exposure (Page 400).

• The PMI standards state that Quality control is done throughout the project life cycle and can be performed by all team members in adaptive projects. However for projects managed by the waterfall model the quality control is usually done towards the end of the project or phase, those quality controls are done by specific team members. The advantage of adaptive projects is here quite clear as there is more flexibility in the fact that more people are able to perform it. Furthermore the quality control is being done throughout the project ensuring that the project deliverables meet the set requirements. Project quality is one of the factors that PMI standards identifies in contributing to a successful project (Page 13).

Limitations of Scrum

Some have concluded that agile practices do not work at scale, and that the small team sizes are a constraint. What works well for small teams and small projects doesn't transfer well to the whole organisation. There are a number of framework that tackle this problem like for example the Scaled Agile Framework SAFe. What that framework does is not changing the sizes of the teams rather how they are organised. Ken Schwaber also introduces ways of scaling Scrum with examples in his book Agile Project Management with Scrum. However he also acknowledges that scaling can be very difficult.

Team members have to be cooperative, self organising and willing to follow the Scrum framework. Getting into this framework and starting to use it can take time, as it is important to implement it in its entirety to get the full benefits (Page 13) . There are frequent meetings so the team members have to be willing to engage in. A problem could arise when a team member decides to quit during the project as each member of the team has their specific role and is very valuable. Another issue can be to manage the budget as you are working with a flexible scope. However the customers have a fixed budget and time frame. Another disadvantage identified being the visibility of the project progress this can be more clear where deterministic project management approaches are used with detailed plans using e.g. Gantt charts and work schedules.

PMI members were concerned when they downloaded the new edition of the PMBOK guide, as they noticed that at the same time they received a copy of the Agile Practice Guide[7]. Some asking if now everything should turn Agile. However it needs to be acknowledged that you shouldn't make all projects agile, you need to evaluate what approach fits best. In cases where you are working with a predictable environment, where you know how the timeline will evolve then Agile Project Management methodologies like Scrum aren't the way to go. When trying to identify some type of projects that are not effectively managed with Agile Project Management methodologies some have pointed out construction projects. The reason for that being that in construction changes are expensive and construction projects tend to be sequential. However at the same time others claim that it could be used for construction when applied correctly. So it can only be emphasised once more that each case has to be evaluated and from that the best approach defined.

Annotated bibliography

• Schwaber, K. (2004). Agile Project Management with Scrum (Developer Best Practices) (1st ed.). Microsoft Press: This book is written by one of the founders of the Scrum framework Ken Schwaber. It provides you with a good overview of the Scrum framework, roles, artifacts and events. Ken also introduces good cases that have both been successful and failed, furthermore he provides good recommendations. This book is well structured, easy to read and the appendixes are very helpful, like for example the Definition table which lists key words used in the Scrum Framework. This book would be suitable for beginners as well as experts. However it can be recommended for beginners to start by reading the Scrum Guide, which is listed here below.

• Schwaber, K & Sutherland, J (November 2020) The Scrum Guide; The Definitive Guide to Scrum: The Rules of the Game: This guide is written by the founders of the Scrum framework. The guide is short (13 pages), on point and can be considered a quick read. It can be said that this book describes Scrum in simple words. When you have finished reading it you should have a good understanding of the definition of Scrum. In the guide the authors emphasise that the Scrum Framework is free and all you need to know is provided in this guide. However it must be said that this guide gives quite high-level overview of the Scrum Framework. Therefore it would be recommended to read books that are more specific about the topic, like the previously mentioned book by Ken Schwaber to gain deeper understanding.

• Project Management Institute, Inc. (2017). A Guide to the Project Management Body of Knowledge (PMBOK Guide)(6th ed.). Project Management Institute, Inc (PMI): This book provides a set of standard terminology and guidelines for project management. So everything you need to now in regards to project management and topics relevant to that. This book is reviewed frequently so it is kept up to date. What is great about this newest edition from 2017 is that there is additional input on adaptive project management methodologies. Where they have taken into consideration adaptive environment which is highly relevant to individuals wanting to inform themselves about the Scrum framework, an adaptive, Agile Project Management Framework.

• Sliger, M. (2011). Agile project management with Scrum. Paper presented at PMI® Global Congress 2011—North America, Dallas, TX. Newtown Square, PA: Project Management Institute: This is a short article that gives good overview of the Scrum framework, in particular the application. The article uses relevant figures to support the text. It introduces the relevant tools for Scrum like for example the Scrum Board and Burndown charts. Furthermore it brings up good questions, provides good examples as well as comparison between the Scrum framework and more traditional approaches.