Being “agile” has become a popular aim in many organizations. However, agile project management is actually a group of different approaches and methodologies rather than a methodology itself. Scrum is one of the most popular agile project approaches (we will discuss later whether it is a methodology) thanks to its widespread and easy-to-understand principles.
Agile Project Management
The foundation of agile project management is a set of 4 values (see screenshot of agilemanifesto.org below) and 12 principles that were set out in the Agile Manifesto in 2001. It defines an alternative and, in some cases, a more efficient approach to software development (although its use goes far beyond that nowadays) compared to traditional project management approaches. “Waterfall” is a common example of such approaches to so-called predictive projects.
Screenshot of agilemanifesto.org (retrieved on 12 Oct 2019)
The values and principles of agile project management are to some extent similar to those incorporated in the Scrum framework. Scrum is in fact the most popular way of setting up agile projects although there are numerous other agile frameworks. Read our dedicated article “What Is Agile Project Management? Definition and Methodologies” where we introduce agile project management and agile methods.
What Is Scrum?
Scrum is a framework for agile projects developed by Jeff Sutherland and Ken Schwaber who presented it for the first time in 1995. Its principles and practices are set out in “The Scrum Guide” (download here). It shall help people “address complex adaptive problems, while productively and creatively delivering products of the highest possible value”.
The framework consists of the theoretical foundation, the team composition, scrum events, and artifacts as well as their “definition of done”.
Scrum is comparatively lightweight and easy to understand – the Scrum Guide has only 19 pages, compared to the more than 700-pages thick PMI Project Management Body of Knowledge that contains the standards for the management of traditional predictive projects.
However, the creators point out that Scrum is “simple to understand, difficult to master” – a prophecy many Scrum practitioners would probably agree with.
Is Scrum a Methodology?
There is indeed an ongoing discussion among experts on whether Scrum is a methodology or just a framework. The creators state that “Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques” (The Scrum Guide 2017, p. 3).
A methodology is commonly defined as a strategy or set of the methods applied to achieve a certain result (short summary of the Wikipedia definition).
Technically, the generic Scrum framework itself does not fully meet this definition of methodology, given its non-prescriptive approach and the encouragement “you can employ various processes and techniques”.
This interpretation is also in line with a statement on scrum.org, an organization founded by the co-creator Ken Schwaber, which states:
“Scrum is not a methodology. Scrum implements the scientific method of empiricism. Scrum replaces a programmed algorithmic approach with a heuristic one.”
However, when Scrum is implemented in organizations and teams, it actually might rely on a set of processes, techniques and methods defined by the team itself. In this context, teams are often using the generally accepted scrum practices which consist of tools and techniques that facilitate the application of Scrum such as user stories, story points, task boards and burndown charts (source: “Head First Agile” by Jennifer Greene and Andrew Stellman, chapter 4)
It can therefore be argued that such tailoring and customization – i.e. the way the Scrum framework and supplemental practices and techniques are adopted and applied by a team – turn Scrum indeed into a methodology within the specific organization, project or team. We decided to include “Scrum methodology” in the title of this article – even though we anticipate that not everyone might agree – as it is not only covering the generic framework but also common practices and techniques (besides contributing to the discussion whether Scrum is a methodology or not).
This perspective is also reflected in the day-to-day language where “Scrum methodology” is actually a relatively common term – just google it to see it yourself. However, it remains to be said that this terminology is not exactly in line with the creators’ claim of Scrum being a generic framework.
What Are the Scrum Values?
Scrum teams are supposed to have five core values:
- openness,
- respect,
- courage,
- focus, and
- commitment.
These values shall be lived by the team and facilitate a trustful, open and therefore efficient environment. As the Scrum framework basically encourages teams to explore solutions rather than applying a set of pre-defined techniques, those values are crucial for the implementation of Scrum.
What Is the Structure of a Scrum Project?
As Scrum is a comparatively light-weight framework, the structure of a Scrum project is straightforward – at least in theory.
The Scrum framework introduces 3 roles:
- the product owner responsible for maximizing the value of the product,
- the self-organizing development team that is creating the product(s) and increment(s), and
- the Scrum master who is a servant leader to the team, the product owner and the organization.
The core of Scrum projects is the timeboxed sprint. It consists of several Scrum events, ranging from the sprint planning through daily scrums to the retrospective.
Outputs created during a sprint are called Scrum artifacts. These include the product backlog, the sprint backlog, and increments. One of the key aspects is a single definition of an increment being “done”.
Read on for the details.
Scrum Team and Roles
Product Owner
The product owner represents the business side in a Scrum project. He is managing the product backlog in order to maximize the value of the product that is created by the project.
Part of this is bringing the items into an order with the most valuable items on its top. This is important to make sure that those items with the most value are developed first, given that usually not all items of the product backlog can be developed and deployed.
In addition, a product owner provides advice to the team and therefore ensures that the development team fully understands the requirements.
The Scrum Guide emphasizes that the product owner is one person who is solely responsible for the above actions. One of the common mistakes when organizations switch to Scrum is that they replace this role with a committee. However, this tends to put the efficiency of the Scrum framework at risk, as it increases complexity and slows down the decision-making. The Guide suggests that the product owner might be representing a committee while she or he remains solely responsible.
Development Team
The development team, ideally consisting of 3 to 9 cross-functional team members, is performing the operational work that is necessary to create the increment(s). It is self-organizing which means that the team is encouraged but also committed to applying the way they deem to be the best in order to get the work done.
It is in fact solely the team’s responsibility to determine how to develop the increments from the backlog items. Nobody is allowed to request them to do this in a certain way – including the Scrum master whose role is that of a servant leader to the team rather than a manager or supervisor.
Scrum requires that the development team consists of resources with all the skills that are necessary to create the project results without appointing certain roles or titles to its members. If the team size needs to be larger than 9 people, it is technically not in line with the Scrum Guide – however, one of the scaled Scrum frameworks can be applied to maintain a Scrum-like project setup.
Scrum Master
The Scrum master’s role as a “servant leader” is comparable with a coach, trainer or ambassador. It deviates significantly from the tasks and responsibilities of a traditional project manager. This is because the self-organizing development team does not require to be directed or managed, tasks do not need to be delegated as the team is pulling them from the backlog, and planning processes are generally lean in Scrum projects.
A Scrum master is however supposed to maximize the value creation by helping everyone inside and outside the project to understand Scrum and facilitate the interactions between product owner, development team and the organization that is adopting Scrum. For instance, he is responsible that the mandatory events during a sprint take place and do not exceed the prescribed timebox.
You will find a list of the exact tasks in relation to each of these parties in the Scrum Guide.
Sprint and Scrum Events
The “sprint” is the core activity of Scrum, it is timeboxed with a fixed and unchangeable duration during which the development team is creating the increments based on the sprint backlog. A sprint lasts for a maximum duration of 1 month with 14 days being also common in practice. Immediately after finishing one sprint, a new sprint is starting.
Sprints consist of a number of different events:
- sprint planning,
- daily scrums,
- development work,
- sprint review, and
- sprint retrospective.
The sprint duration cannot be changed, i.e. even if the sprint backlog still contains items at the end of a sprint, the sprint ends and remaining sprint backlog items go back to the product backlog. However, a sprint can be canceled if the product owner decides to do so which should be limited to exceptional cases though. The completed increments need to be reviewed regardless, and incomplete items of the sprint backlog are returned to the product backlog.
Sprint Planning
During this meeting, the work to be done during the sprint is planned by the product owner, the development team and the Scrum master. Together, they form the so-called Scrum team.
For the sprint planning, the product backlog, previously created increments, the velocity (or another measure of the team’s productivity during previous sprints) and the capacity of the team are considered.
While the product owner introduces the objectives of the sprint, the entire Scrum team is determining the sprint goal. This goal provides the overall guidance for the development team’s work during the sprint.
The development team is solely responsible to draw items from the product backlog into the sprint backlog, as it is the only party able to assess how much work could be completed during the sprint. In this process, the product owner is providing advice and clarifications on items contained in the product backlog.
The product backlog items selected for the sprint and the plan for their delivery form the sprint backlog.
Daily Scrums
The daily Scrum is a daily 15-minute meeting of the development team in which each team member reflects on:
- what she or he contributed on the previous day for the team to achieve the sprint goal,
- what she or he is going to contribute on the current day, and
- whether there are any impediments.
Further technical discussions are not allowed during the daily scrum and shall be deferred to dedicated meetings. In order to improve discipline and stick to the 15-minutes constraint, many teams actually conduct the daily scrum in the form of a stand-up meeting.
Sprint Review
The purpose of the sprint review is to inspect the increment and update the product backlog, if applicable.
It is attended by the Scrum team and the stakeholders and provides the opportunity to get the stakeholder’s feedback and collaboratively enhance the product. It is timeboxed to 4 hours for a 1-month sprint (shortened if the sprint duration is shorter).
The product owner is responsible for inviting the attendees (while the Scrum master is making sure that such the event takes place) and introduces the current product backlog and the items that have been completed during the sprint. The development team discusses its work and demonstrates the increments. All participants then discuss the next steps while taking changes to the environment and project constraints into account.
A revised product backlog is usually the output of the sprint review which in turn serves as an input for the sprint planning event of the subsequent sprint.
Sprint Retrospective
The sprint retrospective is a 3-hour meeting (shortened, if the sprint lasts less than a month) that facilitates the Scrum team’s reflection on the sprint. It involves identifying positive elements of the last sprints, areas of possible improvement and a plan to implement these lessons learned.
Scrum Artifacts
Product Backlog
The product backlog is the single source of requirements, listing all of them together with features, functions, enhancements and fixes that are supposed to be developed.
The backlog contains those items in an order that is determined by the product owner based on the value (and risk) of each item. It is frequently updated to incorporate learnings and changes – a process called backlog refinement.
Sprint Backlog
The sprint backlog is a forecast of the realized scope of the increment at the end of the sprint. It comprises of:
- the items the development team chose from the product backlog to be developed during the sprint and
- a plan for their delivery and for achieving the sprint goals.
The development team can decide to change the sprint backlog during the sprint to reflect changes or updates.
Increment
The increment is defined as all product backlog items that have been completed during the sprint plus the value of increments created in previous sprints. According to the Scrum Guide, an increment is a “step toward a vision or goal”.
We mentioned previously the need for a single definition of “done” which is applied to the increment:
Definition of “Done”
Working with a single definition of done all Scrum team members agreed on prevents any expectation gaps stemming from a different understanding of what should be delivered. Its criteria are set by the team and follow, as a minimum, the definition of done required by the organization.
A completed backlog item has to fulfill the definition of done in order to be recognized as being done.
Additional Scrum Practices
Scrum is intended to be a framework that sets the stage for the project team to develop their own approach to achieving the project and sprint goals. However, this does not mean that each and every team needs to reinvent the wheel. A number of techniques have evolved over the years that have proven to be highly effective if the project decides to adopt and tailor them.
Previously, I mentioned the generally accepted scrum practices which are described in detail in the book “Head First Agile” by Jennifer Greene and Andrew Stellman (chapter 4; this book is not only informative but also entertaining – it was actually one of the main pillars of my PMI-ACP exam preparation). At the time of writing, parts of that chapter were also available on the publisher’s website.
In this article, I will focus on four generic key techniques. Note that there are hundreds of techniques, deviations and other best practice methods for Scrum – while this offers a good template for almost all use cases in a project, it can be quite overwhelming. For Scrum newbies, it can be sensible to choose a few well-established techniques for the first sprints and adapt and supplement them once the team has developed some experience in scrum.
User Stories
Instead of technical designs or specifications, agile projects are often using user stories to describe the requirements. The key is that each user story is written from the perspective of a user and represents one single piece of usable functionality. A sprint usually consists of several user stories that are managed in the sprint backlog.
Examples (recall the above delivery app example):
- User story for in-app payment: As a user of the app, I want to be able to pay my order directly in the app rather than handing over cash to the delivery guy.
- User story for the order notification: As a restaurant owner, I want to receive a notification on my phone once an order is received, so that I am able to process orders faster
User stories are usually the basis and reference for estimates.
Story Points and Velocity
Rather than estimating efforts, Scrum teams use story points to estimate the effort it takes to develop and deploy a user story.
Story points do not have a prescribed scale and they are not convertible into man-days or cost. The scale is set by the team (some are using “T-shirt sizes” to facilitate the estimate) and indicates the relative value of a user story compared to other user stories.
The number of story points completed during a sprint is referred to as velocity.
Task Boards
Task boards consist of columns indicating the status of the implementation of user stories. They comprise of columns for backlog or to do, in progress (some teams break it further down) and done. The user stories of the sprint backlog are added to the first column at the beginning of the sprint and wander to the right side as the team moves forward during the sprint.
(created with the project management software “Trello”).
Some teams prefer using whiteboards and sticky notes or writing for their task boards. Other teams, in particular those not sharing the same space all the time, may prefer a software-based task board.
Burndown Charts
A burndown chart shows the line of remaining story points during the sprint (assuming a linear burn off rate). During the sprint, the amount of story points actually done is plotted in this chart as well. Thus, it is easy to spot how many story points remain to be completed and whether the performance is in line with the schedule.
What Are the Advantages and Disadvantages of Scrum?
Like other agile frameworks, Scrum aims to establish a trustful environment with lots of operational decisions to be made by the development team, where quick Incremental delivery and getting feedback are crucial to produce good results and avoid wasted efforts (e.g. developing something that was initially requested but is not needed anymore).
Scrum works usually well, in particular for but not limited to IT-related projects, if it is established with the right mindset and if the size of the teams does not exceed 11 people (incl. product owner and Scrum master).
However, there are also many examples of companies and projects where the switch to Scrum did not go well. Reasons can be the implementation approach (e.g. implementing a prescriptive set of Scrum-related processes top-down), replacing the product owner with a committee (which may slow down things), keeping on requiring the same documentation and progress reporting as in traditional projects, and many other reasons.
For many of those failed Scrum implementations, the root cause is the lack of a proper mindset. To be successful in the long run, the first step is that the team and all stakeholders live the Scrum values, followed by the team developing their own approaches to resolve things. At the same time, the management has trust in the project’s capabilities and refrains from requiring detailed documentation, involvement in everyday decisions, traditional progress monitoring, controlling and reporting, etc.
In such an environment, Scrum proved to be a successful framework that is used by numerous companies and teams around the world and even became industry best practice in many software development niches.
Scrum might not fit for every project though. Larger projects and project teams spread over different locations require a scaled derivative of Scrum. Projects with certain characteristics – e.g. driven by regulatory or legal requirements or in complex environments with many interdependencies – may be better off using traditional approaches.
Last but not least, a proper introduction of Scrum requires some time and – to some extent – tolerance for “trial and error”. As the right mindset and its values need to be developed rather than simply “switched on”, a switch to Scrum might be less effective than traditional approaches during the transition period while the benefits are realized in the long run.
Conclusion
In this article, we have seen the different aspects and requirements of the Scrum framework, supplemented with examples of good (and not so good) practices of applications of the Scrum framework.
While Scrum proved to be highly efficient for certain types of projects and comparatively small teams, the key is to get into the right mindset first.
Although there are numerous established processes and techniques that can be used within the Scrum framework, it will only be successful if the organization and the team actually live the Scrum values and if the team, rather than the management, decides which processes and techniques work best for them.
Let us know if you are willing to share your experience with Scrum projects and the Scrum introduction in established organizations.