Scrum Definition – A Comprehensive Overview

Scrum Definition – A Comprehensive Overview

What is the Scrum Definition

It is a lightweight process framework. It is simple to understand. It is difficult to master. The Guide says that it is not a process, technique or a definitive method. This means that each team or project is allowed to define its own terms, within the framework.

This results in a Scrum process or technique which is unique to the project or team. A Scrum is composed of Teams with distinct and individual roles, artifacts, events, and rules. None of these are fixed except the underlying mindset embodied by the rules of Scrum. The rules themselves are not fixed, but, like Scrum, can be made and then revise according to the Team.

As a framework, Scrum:

  • has a disciplined process of project management;
  • promotes self-organization;
  • has accountability;
  • frequent inspection of the process, results, and status;
  • encourages adaptation;
  • a set of best practices for assurance and delivery of quality software;
  • aligns business development with the Agile Manifesto.

As a lightweight process framework, Scrum has properties which make it look like a methodology. However, since the Scrum as a methodology is unique to a given project, it can be only be considered as a methodology within the context of implementation.

Vital to the Scrum process is time-box. This ensures that activities start and finish on time. This strict adherence to the time-box translates to better time management across the project. More projects are finished on time. In addition, there is a better prioritization of things to do. The Sprint results are also more realistic. Developers have a say on what they can do and what they can defer doing. They also have a better understanding of the things they are doing.

Transparency in the process is inherent in Agile and in Scrum. Stakeholders are represented by the Product Owner. The Scrum Master is not supposed to directly communicate with the Product Owner. If the product owner needs a certain revision, he will be entertained and the revision is incorporated in the next iteration. The insertion of revisions in the project scheduling helps the Product Owner, the stakeholders, and the Development Team.

In most instances, revisions which are deferred until after the project results in a product which does not reflect the new project requirements. Addressing the new project requirements while implementation is still ongoing makes sure that the product will meet the current criteria.

Project transparency also allows stakeholders to see the project as it develops. They can see working products as sprint increments. Revision requests reflect the updates of the Product Backlog.

The nature of the short sprints results in more commits. Ideally, the sprints can be planned to create working product updates which can be released to the market immediately.

The iterative process starts with the Product Backlog, which is a to-do list for the whole of the project. Each Sprint starts with a Sprint Planning and results in a Sprint Backlog. During the Sprint, Daily Scrums are conducted. These are short standup meetings which let the Team members catch up with one another’s work.

The Sprint is typically for two weeks, at the end of which a Sprint Review is conducted. The Sprint Review decides on whether the Increment is for release or not. A Sprint Retrospective follows the Review where members look at their effort and correct for any errors in execution during the given Sprint.

The Scrum process includes the following events or ceremonies:

  1. Backlog organization. This is the initial activity where the various features and components of the product are listed and studied. Each item is also given a level or estimate of complexity. The complexity level is based on the Fibonacci sequence. This is not expected to be a final list. Instead, it is expected that the end product is unknown, and those additional items will reveal themselves during the duration of the project.
  2. Sprint Planning. Items on the product backlog are studied and prioritized. The result is a list of items which can be done within the duration of the next Sprint. The list is called the Sprint Backlog and those on the list are also given a level of complexity according to the latest understanding of the project. Among the items on the list is the Sprint’s Increment.
  3. Sprint. This is the short and iterative implementation stage. The Development team sits down and completes the items within the Sprint time-box. The Team is also responsible for defining when a backlog is “done,” “releasable” and others.
  4. Daily Scrum. The daily standup meeting of Team Members. There are several rules of thumbs in play in the Daily Scrum. The attendance should fit the “2 pizza” rule: the number of members should not be more than what could be fed with 2 pizzas. This is an arbitrary rule created by Jeff Bezos to determine the ideal number of team members (7-10).

Another rule is the length of the meeting. To have a productive standup meeting, it should be no more than 15 minutes. The Scrum Master makes sure that there is a meeting. Nobody reads the meeting. It is not a status meeting.

Depending on the structure of the daily scrub or the standup, the team may have a short list of items they can discuss. The standup usually focuses on developments and how they affect the Sprint Goal:

  • What did I do yesterday that helped towards the Sprint Goal?
  • What am I going to do today to help towards the Sprint Goal?
  • What obstacles do I foresee?

There is no need for the attendees to bring their calendars or their list of accomplishments. The most important part about the daily scrum is to present pressing concerns and to touch base on items which have an impact on the Sprint Goal. This is a time-boxed event with the aim of maximizing productivity and minimizing meetings.

Traditional status meetings result in long agendas, where people discuss a lot of things leaving them away from their desks. This is frustrating for developers who may not be able to work productively during the course of the meeting.

  1. Sprint Review. The team meets to wrap up the Sprint during the Sprint Review. Increment presentation or release, if any, is also done during the Review. It is a closeout of the Sprint and the team takes stock of accomplishments, removing the “done” items out of the Product Backlog.
  2. Sprint Retrospective. The Retrospective is a separate activity from the Review. During the Retrospective, the team reflects on what they did correctly, and what went wrong. This time is spent understanding the “learnings” during the Sprint and in improving succeeding sprints.

The Scrum events have a fixed time frame, called the time-box. Time-boxing is a major feature of Scrum and it is fixed beforehand. There are no extensions. For instance, whatever item is not “done” during a Sprint, is sent back to the Product Backlog.

An activity is designed in a way where it will finish within a fixed time frame like daily scrums are stand up meetings held at the same time of day, every day, and for only 15 minutes. Other time-boxes have recommended lengths, like the Sprint which is recommended to be only 2 weeks long. Events are time-boxed to allow the Team to focus on what is important.

Scrum Artifacts

Scrum Artifacts

Sprints are noted for creating Increments which are important to the project. However, there is no mention of a project documentation per se. Traditional project management’s documentary output is not done in Scrum. These include any specifications, requirements and QA testing materials. These are usually approved by stakeholders before they are accepted as deliverables, and in Scrum, not doing these things is a big saving in time and resources. There are only three artifacts in Scrum: Product Backlog, Sprint Backlog, and Increment.

  • Product Backlog. This is the list of items which need to be done in order to finish the project. The list is created during the Backlog Organization stage. It includes the final product, its components, and other items which are necessary for building the project’s goal. The Product Backlog is understood to be incomplete. Other items would be included in the Product Backlog as the project progresses. This growth is the result of the empirical approach of Scrum. It presumes that the project will evolve and that not everything about it is known at the start. As the team develops a better understanding of the project, it will discover new items, or there will be a need for these new items.
Product Backlog

The product backlog is a dynamic document which is researched, prepared and maintained by the Product Owner. Some items in the Product Backlog may not exist at the start of the project. These include project unknowns which come to light during the development. These can also project revisions which need to be included in the product.

The nature of Scrum allows for these changes to be included in the project, resulting in a product which is updated as it is being developed. This takes into account the changing conditions of the intended use. If an event occurs which might impact the use of the product, the Product Owner can include an item which effectively updates the product features, the Product Backlog and directions of the project.

  • Sprint Backlog. The list of items to be done during a Sprint is called the Sprint Backlog. It is a subset of the Product Backlog and should be finished during the sprint. The team decides what items to include in the Sprint Backlog. The process of creating the Sprint Backlog serves as a team commitment to finishing the list.
Sprint Backlog

One method of creating the Sprint Backlog is called the MoSCow, which is short for:

  • Must Have. These are the top priority for the Sprint and at the end of the Sprint should become Increments. The Sprint fails if these items are not delivered. Must have items can also be co-requisites of an increment or pre-requisites of succeeding increments. There is no use going through the Sprint without these items.
  • Should Have. These are fun-to-have items which can be added to the development if there is time within the Sprint. These are second priority, an important but not vital, or not needed at this point. It could be left out, but the solution would still work without it. It is also possible that there is a pre-requisite to the item, or that a workaround is required or needed instead of this item.
  • Could Have. This has less impact on the project or on the sprint. It may be time-related and it is not needed until some time in the future. It may be a desirable feature but is not important for the completion of the project or increment.
  • Won’t Have at this time-boxing. It may not be needed at this Sprint. It can be deferred to a later date. It can also be something which is outdated and may be removed from the Product Backlog at some point.

The Must-Have items are included in the Sprint Backlog, while all the rest are maintained in the Product Backlog. Creating the Sprint Backlog prioritizes items which can be made immediately, and improve the product. It presumes that the Increment can be a candidate for release. Sprints allow the team to release a new update after every Sprint.

  • Increment. This is the output of the Sprint. The name implies that the output is an improvement or increase in functionality over the prior product. A Scrum project can be used for product improvement or updates, resulting in new updates every two weeks. The team decides on the definition or parameters of a “done” Product Backlog. Not all “done” backlogs become increments. And not all increments are released. It is up to the Product Owner to decide whether the Increment can be released.

Large complex projects can have incremental improvements to a product. Alternatively, the increments can be small features of a larger product. At the end of development, a Sprint or several Sprints can be dedicated to product integration, resulting in a single large increment.

Origin and History of Scrum

Scrum History And Origin

Although Scrum is more well known for software development work, it has its roots in Agile and other manufacturing methodologies. Scrum has direct analogs answering concerns raised by structured software design and development (SSDD). Was meant to make sense of and use engineering concepts to software development, especially in coding.

One of the software engineering paradigms introduced as an improvement over SSDD was RAD and prototyping. These were meant to result in faster development. The problem with SSDD was the emphasis on documenting the old and the proposed system. Everything had to be approved before the implementation started. This resulted in a lengthy process where the development was not able to capture changes in the requirements while implementation was ongoing.

One of the software engineering paradigms introduced as an improvement over SSDD was RAD and prototyping. These were meant to result in faster development. The problem with SSDD was the emphasis on documenting the old and the proposed system. Everything had to be approved before the implementation started. This resulted in a lengthy process where the development was not able to capture changes in the requirements while implementation was ongoing.

Agile and Scrum tries to address these changes as they arise. In so doing, these advocate an approach which acknowledges that the final product will be different from the initial goal. It also takes into account that most of the changes incorporated during the development came about because of the development itself. In essence, the Agile mindset understands that development is trying to do catch up with a moving target and that while development is ongoing, there is more understanding about the goals.

However, traditional development tries to incorporate these changes after the product has been delivered. This evolutionary approach takes a long time and can only be done by going through the same long process. Even if the goal was finished, it still results in delays and in going over the budget. In contrast, Scrum insists that the timeframe does not move and that the project estimate is adhered to as close as possible.

The development would prioritize features and increments which would bring the most benefit within the given increments. This results in a product which is updated to meet current needs once it is delivered. The development is on time, resulting in a budget which closely approximates the original cost. At the same time, the development could be shorter, resulting in a continuous project which delivers more in shorter chunks of time.

The roots of Scrum was in a paper published in the Harvard Business Review in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka. The paper discussed a product development approach which promised faster product development and flexibility in procedures.

In 1993, Jeff Sutherland first used Scrum for a software project. Two years later, Sutherland, along with Ken Schwaber started on work to make Scrum a formal process. The pair was also in attendance when Agile pioneers met in Utah in 2001 which resulted in the Agile Manifesto.

The following year, the Scrum Alliance was formed and started offering Scrum Master certification courses. Separately, Sutherland created Scrum, Inc., which offered Scrum Master certification classes, while Schwaber left Scrum Alliance in 2009 to found Immediately after, started offering a Professional Scrum series.

2010 saw the first publication of the Scrum Guide as written by Sutherland and Schwaber. Its sixth iteration was released in 2017.

The history of Scrum is tightly bound with the codification of its ideals. The training started first, before the Scrum Guide. In hindsight, this is in line with the concepts of Agile and Scrum to deliver quality products, like Scrum as a framework. In the same manner, the Scrum Guide iterates with revisions and is released like an Increment after a Sprint.

The changes in the real world application of Scrum makes its way to the Scrum Guide via community user feedback. Necessary and vital improvements are added to the succeeding iteration. These revisions keep the Scrum Guide, and Scrum implementations updated.

The Project Management Institute revealed that there are more certified Scrum Masters compared to certified Project Managers. This shows the progress that Scrum has made in terms of the demand and number of Scrum practitioners. It also shows the extent of use and acceptance for the framework.

Scrum has been adopted by a wide range of companies. Google used Scrum in their AdWords project, while Adobe used it in Lifecycle, Soundbooth, and Audition. Games by Wooga were also built using Scrum, as well as Street Fight IV. Other companies which have used Scrum include IBM, Microsoft, Yahoo, NPR, John Deere, GE, Saab, and others. Web services companies like Spotify, Amazon, Netflix, and Etsy also use Scrum.

A 2017 survey found that Scrum projects have an average of 5 sprints per Scrum project. The average length of those sprints was 2.4 weeks, and the average duration of a scrum project was 11.6 weeks.

Scrum Community and Learning Materials

There are plenty of forums and communities which discuss Scrum. These are usually populated by new Scrum practitioners who want to learn more as well as veteran users who want to share their experiences. Besides Scrum forums, there are also companies which have evolved as evangelists spreading the news about Scrum.

Scrum forums and communities also serve as a central repository for books, magazines, and resources. In addition, the growth of online web resources has led to open discussions about using Scrum. For a practitioner, the following websites provide information and examples about Scrum:

  1. The Scrum Master.
  2. Serious Scrum.
  3. Emerald Hill.
  4. Visual Paradigm.

Ready to increase your work productivity?

#1 rated scrum tool

Try Monday Now Project Management Tool

  • Proj​ects and Tasks Management
  • User Stories & Sprints
  • Users Roles
  • Scrum & Agile Methodology
  • Time Tracking and much more...
Close Menu