Latest revision as of 22:22, 22 March 2022

[edit] Introduction

Scrum was introduced in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka with an article named: ‘The New New Product Development Game’, published by Harvard Business Review^[1]. In the early 1990s it was further developed by Ken Schwaber and his company. Even though Scrum is spelled in all capital letters a lot of places, it is not an acronym. The word itself originated from rugby, where the term means a formation of players or a team. Scrum was made to help provide organizations flexible solutions to problems. Scrum is an iterative process, with the time frame most commonly being between 2 weeks and a month. This time frame is called a sprint in Scrum terminology. However, this varies a lot depending on the organization needs. Scrum has in recent years become a very popular project management framework. It is commonly used in companies who wish to become agile or lean. Together with the Kanban board, the Scrum framework has become an essential tool within agile and lean management.

Within the framework the Scrum Master manages a group through the following steps:

1. A Product Owner orders the work for a complex problem into a Product Backlog.

2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.

3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

4. Repeat. ^[2]

This article will go through the steps of the Scrum framework and the ideas behind them.

[edit] Values

The Scrum framework is based upon 5 core values that are meant to help illustrate some of benefits of the framework. The five values are:

- Courage

- Focus

- Commitment

- Respect

- Openness

For a Scrum process to be successful, the scrum team must keep these values in mind. The teams must be courageous so that they can use this framework to solve tough and complex issues. Focus and Commitment are also essential. When working with complex issues it is important that the team participating in the process are focused and committed. Finally, this framework is used by teams of people and therefore the participants are forced to work together. To help ensure conflicts are avoided, participants are encouraged to be respectful and open towards their fellow teammates.

[edit] Team

As mentioned before, the Scrum is performed by a small team of people. A Scrum team consists of a Product owner, a Scrum master and developers. The Scrum team is supposed to be self-managed and consisting of people with the necessary competences to achieve the goal. In order words, the teams should not be relying on any other manager or employees. The Scrum team can vary in size, however, smaller teams are preferable since it helps the team stay nimble and agile. According to the Scrum Guide^[2], a Scrum team should rarely exceed 10 people, but it does of course depend on the objective or goal of the organization.

[edit] Developers

One part of the Scrum team is Developers. Ken Scwaber and Jeff Sutherland describes developers as follows in their Scrum Guide: “Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.”^[2]. In addition to that, they are responsible for making the product at the end of each sprint. You do not need any specific skill in order to become a Developer, since the skill requirement relies heavily on the objective. The competences and background of the Developers varies a lot, however, there are a few characteristics most great Developers should possess, for example, the ability to work together in teams. However, according to the Scrum guide developers are always responsible for:

• Creating a plan for the Sprint, the Sprint Backlog

• Instilling quality by adhering to a Definition of Done

• Adapting their plan each day toward the Sprint Goal; and,

• Holding each other accountable as professionals. ^[2]

[edit] Product Owners

The product owner is often the key stakeholder of the project^[3]. Their main purpose is ensuring the maximization of the value that the project intends to provide to the end customer. They do this by managing the product backlog which is an ordered list of the desired features the end product should have.

Product owners often takes the perspective of the customer or consumer of the product. This customer centric perspective is meant to help ensure that the product actually delivers on the goals set in the beginning of the process. The product owner is the role within the Scrum framework that acts the most like what a project manager does in a traditional project group. It is fine for a product owner delegate work within the Scrum team, but the product owner is accountable of not only the daily executions of Scrum events but also the final product. A product owner is often a person with knowledge of both the business and technical side of the project and can therefore act as a mediator between developers with different backgrounds. It is also recommended that the product owner is someone with great leadership since the person is in charge of the entire Scrum team and the process. The Scrum guide also emphasizes the importance of their only being one single person as product owner within every Scrum team: “The Product Owner is one person, not a committee. The Product Owner may represent the needs of many stakeholders in the Product Backlog. Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.”^[2]. This also means that, in order for a product owner to be successful, the other members of the Scrum team must trust and respect the product owner decisions.

The product owners key responsibilities can be summed up as follows:

- Defining the vision

- Prioritizing the product backlog

- Taking an overview of development stages

- Handling communications

- Knowing what the client needs

- Evaluating progress ^[3]

[edit] Scrum Master

In short, the Scrum master is responsible for the Scrum team’s effectiveness. A Scrum master is someone with a deep understanding and knowledge of the Scrum framework. This includes Scrum team roles, Scrum events and Scrum artifacts. One of the main responsibilities of the Scrum master is to make sure every participant understands the Scrum process and their individual roles and responsibilities. In addition to that, the Scrum master also helps outside of their respective scrum team. They can also help the organization around the Scrum team to have a better understanding of how the framework works. The Scrum master thereby serves the Scrum team, the product owner and the organization in numerous ways. They help team members with self-management and ensuring all of the events are done within the set timeframe. They help product owners with planning and backlog management, and finally they help the entire organization by educating and training employees in the Scrum framework. In order to become an official Scrum master, you have to take a Scrum master certification course. There are many providers of these courses, and they vary in length.

[edit] Scrum events

The entire Scrum framework is built around Scrum events. These events are: The sprint, sprint planning, daily Scrum, sprint review and finally sprint retrospective.

[edit] The Sprint

The sprint is the most essential scrum event. It is through this process that the goal of the entire Scrum framework is achieved. As with other events within the framework, the duration varies. The duration of the sprint depends on the organization and the goal of the framework. However, it is recommended that the sprints duration is at least under a month. It is also recommended that sprints remain the duration, or at least as close as possible, to help create stability and consistency. The sprint consists of multiple events, such as Sprint Planning, Daily Scrum, Sprint Review and finally Sprint Retrospective.

[edit] Sprint Planning

Sprint planning is the very first step of the sprint and kicks off the process. Before starting the sprint a clear goal needs to be set. In this event, the Scrum team has a discussion, facilitated by the product owner, about which items from the product backlog should be included in this sprints sprint backlog. When choosing the sprint goals, it is important to consider that they must be achievable within one sprint and how to actually reach them. To help with this discussion, the scrum guide provides three questions:

Why is this Sprint valuable?

What can be Done this Sprint?

How will the chosen work get done?^[2]

[edit] Daily Scrum

As the name suggests, the daily Scrum is a daily event. This is mostly an event only for the developers of the Scrum team. It is a 15-minute meeting where the developers themselves can plan how they want to tackle the sprint backlog, which was made in the sprint planning. For the sake of simplicity, it is highly encouraged that the daily scrum takes place at the same time each day. Whether that is in the beginning of each workday or at the end, is up to the developers to decide. The focus of each meeting should be to plan the next immediate steps and not a long-term plan for the entire sprint. Since it is often only the developers who participate in the daily Scrum, it encourages self-management and help the developers focus on the tasks at hand.

[edit] Sprint Review

The sprint review is the last step of the sprint itself. This event includes all Scrum team members as well as other stakeholders. These stakeholders could be people such as, customers/clients, upper management or other people within the scrum team’s organization that is interested in the outcome of the sprint. This group of people is often referred to as the review group. In the sprint review, the developers can demonstrate what they have developed throughout the sprint. However, a good sprint review should not just be a presentation by the developers. The developers should include the review team and encourage a conversation. In ‘The Scrum papers’ Jeff Sutherland writes: “The review includes a demo of what the Team built during the Sprint, but if the focus of the review is a demo rather than conversation, there is an imbalance.”^[4]

[edit] Sprint Retrospective

After the sprint is completed is when the Scrum team should perform the sprint retrospective. Here, the team reflects upon the last sprint or older. and discuss what went wrong and what went right. Whereas the sprint review was very focused on the product and whether it fulfilled the product requirements or not, the sprint retrospective is focused on the process or interactions within the sprint. This event is usually facilitated by the Scrum master due to their deep knowledge about the Scrum framework. The main goal of the sprint retrospective is to identify the elements that produced issues or conflicts and try to eliminate them before starting the next sprint. If done correctly, this event can prevent issues and make future sprint more effective. This event concludes the sprint, and the Scrum team should now be ready to start the planning of the next sprint.

[edit] Scrum Artifacts

The Scrum framework includes artifacts, each with their own commitment. These artifacts are essential for the framework and help the Scrum team map their progress.

[edit] Product Backlog

The product is a list of items or objectives, that is needed for the final product or its improvement. It serves as the main overview of work needed to be done by the Scrum team. The product backlog items, and length relies heavily on the type of product goal. It is important to constantly size the product backlog and improve it by further detailing each item into smaller tasks. This is mainly done by the developers of the Scrum team, but the product owner may assist them by providing insight. The commitment of the product backlog is the ‘Product goal’. Every single item on the product backlog must be able to be traced back to the product goal. The product goal is the long-term goal of the Scrum team and may take several sprints to finally achieve. A product is a broad term but, in the Scrum guide they define it as the following: “A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract”^[2]

[edit] Sprint Backlog

The sprint backlog is developed in the sprint planning event. Here the Scrum team select items from the product backlog, that they wish to complete by the end of the sprint. In order words, the sprint backlog is a sub-list of the product backlog which should be achievable within the sprint timeframe. The commitment of the sprint backlog is the ‘Sprint goal’. This is very similar to the product goal, but on a smaller scale. As mentioned earlier, every sprint has a clear goal, and just like the items in the product backlog, the items in the sprint backlog should solely serve the purpose of completing the sprint goal.

[edit] Increment

The last Scrum artifact is the increment. An Increment is a completion of a task which supports the product goal. All increments must be thoroughly tested together to make sure that they all work together. Increments are made within a sprint and are presented in the sprint review but can in some cases be released before the sprint is done. The commitment of the Increment is the ‘Definition of Done’. The definition of done is a clear definition of when a task is considered done. The definition is made by the developers and must ensure that the standard and requirements are upheld and thereby eliminating the release of faulty or low-quality products.

[edit] Scrum and Agile management

Scrum has become synonymous with agile management. Agile is a management style which emphasizes agility and the organization’s ability to quickly react to change in its environment^[5]. Agile management gained popularity in the 2000s after the release of The Agile Manifesto by Martin Fowler and Jim Highsmith in 2001^[6]. It started within the software development industry but has become more widespread in recent years. Proponents of agile management were tired of ‘heavy’ models with a lot of documentation and bureaucracy, which made companies slow to react to changes. The software industry saw a fast development of technology which traditional management methods had a tough time of handling. As the authors of The Agile Manifesto puts it:

“Facilitating change is more effective than attempting to prevent it. Learn to trust in your ability to respond to unpredictable events; it's more important than trusting in your ability to plan for disaster.”^[6]

Agile practitioners will opt for lighter and simpler management tools, with one of the most popular being the Scrum framework. Scrum was designed to be simple and easily applicable to whatever goal to organization wants to achieve. The paper “Agile Software Development Methods: Review and Analysis” written by Pekka Abrahamsson, Outi Salo, Jussi Ronkainen and Juhani Warsta^[7], mentions Scrum as a popular agile development method alongside or frameworks such as: Extreme Programming, Feature Driven Development and The Rational Unified Process.

[edit] Limitations of Scrum

No methodology is perfect. Scrum, just like any other framework, has some drawbacks. Some organizations have experienced trouble adapting this framework to larger groups. This has led some organizations to develop their own variation of the Scrum framework. One of the most popular alternatives to the Scrum framework is the Spotify model. This model splits the entire organizations into groups which are named; Squads, Tribes, Chapters Guilds etc. ^[8]. Scrum also divides responsibility and authority among the team members. This is done to strengthen self-management and engagement. However, this means that if team member is to leave, it can have devasting consequences for the Scrum team. Some people also find it frustrating with the daily meeting, which is a key feature of the Scrum framework. These drawbacks show why it is important for organizations looking to adopt the Scrum methodology, to understand how it may affect them and possibly make their own adaptations.

[edit] Annotated Bibliography

Schwaber, K. and Sutherland, J., 2011. The scrum guide. Scrum Alliance, 21(1) This guide is essential for people to read if they want to know more about the Scrum framework. It has been cited multiple times in this article because it was written by the very inventors of the Scrum framework as we know it today. They are also responsible of certifying Scrum masters.

The Scrum Papers:, Nut, Bolts, and Origins of an Agile Framework, Scrum, Inc. Jeff Sutherland, 2011 This paper dives further into the history of Scrum and contains a more in-depth guide of its different applications. In addition to this, the paper also provides examples of its implementation. This source is great for people interested in reading more about Scrum.

Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta, J., 2017. Agile software development methods: Review and analysis.^[7] As mentioned in this article, the Scrum framework is a popular tool within agile management. If one is interested in Agile management, this paper provides an overview of agile management and different tools within Agile management.

[edit] References

1. ↑ Takeuchi, H. and Nonaka, I., 1986. The new new product development game. Harvard business review, 64(1), pp.137-146.
2. ↑ ^{2.0 2.1 2.2 2.3 2.4 2.5 2.6} Schwaber, K. and Sutherland, J., 2011. The scrum guide. Scrum Alliance, 21(1)
3. ↑ ^{3.0 3.1} Scrum Product Owner,” Available online: https://www.workfront.com/project-management/methodologies/scrum/product-owner#:~:text=What%20is%20a%20Scrum%20Product,marketplace%2C%20competitors%2C%20and%20trends.
4. ↑ The Scrum Papers:, Nut, Bolts, and Origins of an Agile Framework, Scrum, Inc. Jeff Sutherland, 2011
5. ↑ Cohen, D., Lindvall, M. and Costa, P., 2004. An introduction to agile methods. Adv. Comput., 62(03), pp.1-66.
6. ↑ ^{6.0 6.1} Fowler, M. and Highsmith, J., 2001. The agile manifesto. Software development, 9(8), pp.28-35.
7. ↑ ^{7.0 7.1} Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta, J., 2017. Agile software development methods: Review and analysis.
8. ↑ Discover the Spotify model MARK CRUTH Available online: https://www.atlassian.com/agile/agile-at-scale/spotify