The origin of the scrum

The word Scrum comes from the game of rugby. If you want to translate, it can be interpreted as “scrum ball”. Scrum is usually done when there is an accident or violence.

Scrum is a form in which the forwards of both teams stand shoulder to shoulder in a horizontal line, bending over each other and touching their shoulders so that a tunnel is formed underneath. The offending team throws the ball into the tunnel, where the forwards play against each other and kick the ball to their midfielders or defenders, both of whom cannot move until the ball has been returned.

In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published The Harvard Business Review article “The New New Product Development Game”, which was cited as The inspiration for The Scrum framework. In this article, he describes a new holistic approach that draws parallels between developing new products and the sport of rugby.

Then we have to mention two people: Ken Schwaber and Jeff Sutherland.

  • In the early 1990s, Ken Schwaber used an approach in his company called Advanced Development Methods.

  • A Scrum process for the software development industry was first defined and implemented by Jeff Sutherland at Easel in 1993.

Both experimented with the Scrum approach to software development at their own companies, and then in 1995, at OOPSLA ’95 in Austin, they jointly presented a paper that proposed the concept of Scrum. Over the next few years they continued to blend their experience with industry best practices to form what we know as Scrum.

In 2001, Ken Schwaber and Mike Beedle wrote the first Scrum book, Agile Software Development with Scrum, which introduced the Scrum methodology.

In 2001, Jeff Sutherland and Ken Schwaber attended a gathering of 17 people in Utah to launch the Agile Manifesto and The Twelve Principles.

In 2002, Ken Schwaber and Mike Cohn co-founded the Scrum Alliance, which began publishing the Scrum Master certification system and its derivatives.

The Scrum Guide was published in 2010 by Jeff Sutherland and Ken Schwaber and has since been progressively updated to establish a globally recognised body of Scrum knowledge.

Roles in Scrum

With that history in mind, let’s take a look at the three roles involved in Scrum: PO, Scrum Master, and Scrum team.

The full name of PO is product owner. He mainly controls the direction of the product and is responsible for the Why and What of the product. In other words, he should know Why the product exists and What the product is.

Scrum Master is the coaching role of a team, focusing on the quality of interaction between people and eliminating external influences on the team.

A Scrum Team is a complete cross-functional self-organizing Team. There are two words here. One is cross-functional, where the Team has all the skills needed for the job and does not rely on outsiders. One is self-organization, which means that the team operates within itself, and the team can choose how to do it, again not depending on the outside world.

Value roadmap

The value roadmap in Agile is as follows:

The right side of the V is the conventional scrum core. Before we get into scrum, let’s take a look at some of its prerequisites and artifacts (step1 through step3 on the left).

  • The first step is to come up with the vision of the project through a meeting, usually initiated by the product owner, which is mainly to clearly define the product vision in line with the company’s strategy.
  • The second step is to get the product roadmap through the meeting, which is also initiated by the product owner. The product roadmap is the product planning based on the time dimension.
  • The third step is the release planning meeting, the release planning of major product features, which will define the high-priority functional modules and release time nodes, and will also point out the possible risks.

Steps 1-3 are best practices outside the Core Scrum process.

Product vision

Product vision is a highly general description of the future vision and direction of the product by the product owner, which should be consistent with the strategic goals of the company or organization. The value of vision is to let the team understand the value of the product, to establish a common goal, to stimulate team morale. A good vision needs to answer the following questions:

  • What is the product?
  • What will the product be?
  • What should the product be?
  • Who is the user?
  • Who are the competitors?
  • How to meet user needs and surpass competitors?

The following template can be used to describe the vision:

  • For :(target customers)
  • Existing :(problems & requirements description)
  • We provide :(product name)
  • This is one :(product category name)
  • It can :(meet the requirements & describe how to solve the problem)
  • Different from before :(product category name)
  • For example :(competing product name)
  • Our products :(core selling points & differentiated features)
  • And in line with: the company’s vision

Product RoadMap /RoadMap

A product roadmap is a timeline overview of product requirements that can be used to categorize, prioritize, and then determine a release schedule. Roadmap is an important tool for product owners to move their projects forward with a clear Roadmap for what should be done at each stage. Effective road map is not only a schedule of emphasis on product distribution and function, also is a dynamic document, according to the actual situation in the process of project update, for example in the early days, on demand, workload, priority, the estimation of completion time does not require also not very accurate, can be continuously detailed as the project.

Here are three ways to look for RoadMap:

Release plan

Scrum builds the product in sprints where features are delivered, usually the most valuable and risky parts of the product are developed first, and when enough valuable, usable product features have been created, the product is ready for release.

So the release plan needs to identify the overall release goals, approximate delivery dates, all features and functions that will be included in the release, highest priority product Backlog items, significant risks, and so on.

The release schedule is not set in stone and the team can adjust it on a sprint-by-sprint basis based on the development process.

Five important things about Scrum

Scrum reduces the need for additional meetings through fixed events. Scrum’s fixed events seem a lot at first glance, but all events are Timebox bound, meaning that each event meeting is limited to a maximum time range.

Sprints, the core of Scrum, are usually no longer than a month, and can be as short as a week or two. If sprints are too long, complexity and risk can increase. Sprint ensures that progress is reviewed and reviewed at least once a month to achieve predictability.

A full Sprint takes time to build a finished, usable product feature. The length of sprints remained consistent throughout the development process. When a Sprint ends, a new Sprint begins immediately after.

As shown above, the top five Sprint events are: Sprint Planning meeting, Daily Scrum station meeting, Sprint review meeting, Sprint retrospective meeting, and Sprint itself. In addition to being an event in itself, the Sprint is a container for all other events, and each event in Scrum is an opportunity for review and adaptation. These events are specifically designed to ensure that transparency and inspection are achieved, and failure to include any of these events results in reduced transparency and a loss of opportunity for inspection and adaptation.

During the Sprint:

  • Do not make changes that are detrimental to Sprint goals
  • Quality targets cannot be lowered
  • The scope of what to do may be clarified and renegotiated between the product owner and the development team as knowledge increases

Backlog Grooming Meeting

Backlog Meeting is called a Backlog Meeting, it is an optional Meeting, usually three days before the sprint Meeting, about 30 minutes.

Participants: PO and Scrum Master must attend, key developers or architects must attend.

Goal of the meeting: Ensure the Product Backlog is complete and tidy.

A well-organized Product Backlog has the following characteristics:

  • Tasks are sorted in order of priority, with the tasks most in need of priority implementation at the top
  • User stories have been developed, including acceptance conditions, detailed requirements, reference prototypes, and any documentation that can assist in illustrating requirements

(1) PO will describe a batch of user stories that the team hopes to implement in the next Sprint to the present team members in the order of implementation. (2) The Scrum Master analyzed the user story with the present members, clearly pointed out the places where the team thought the requirements were not clear, made on-site records, and completed them after the meeting. (3) The Scrum Master analyzes the technical tasks that need to be included in the user story with the architect and present team members. The Scrum Master establishes the sub-tasks first so that the team can more accurately predict the task story points during the sprint planning meeting. (4) After the meeting, PO ensures that any issues raised by the team are resolved before the sprint meeting begins.

Sprint Planning Meeting

Sprint Planning Meeting participants are the entire Scrum team. As a practical matter, the meeting will likely run out of time, so the Scrum Master wants to ensure that the meeting runs smoothly and that everyone understands the purpose of the meeting. The Scrum Master teaches the Scrum team to follow Timebox rules.

The inputs to the Sprint Planning Meeting are the Product Backlog, the latest Product incremental features, and an estimate of the development team’s capabilities (how many features can be accomplished) during this Sprint. The priority of the Product Backlog is an important perspective. The higher the priority, the clearer and more detailed the Backlog. For a low priority backlog, however, the level of detail is lower and may not even be a backlog item (very low priority, used as a placeholder for reminders).

The Sprint Planning Meeting mainly answers two questions:

Topic 1: What can you do this Sprint?

Topic 2: How to finish the chosen job?

Main forms of Sprint Planning Meeting:

The product owner explains the Sprint goal and the product backlog items that need to be completed to achieve that goal. The entire Scrum team works together to understand Sprint’s work.

After setting Sprint goals and selecting product backlog items to complete for that Sprint, the development team decides how to build these features into “completed” product increments during the Sprint. The product Backlog items selected for this Sprint plus the plan to deliver them are called the Sprint Backlog. If the development team feels that there is too much or too little work, they can renegotiate selected product backlog items with the product owner.

The Sprint goal

The Sprint goal refers to the Sprint in which the product backlog is accomplished, and the selected product backlog items provide a consistent function that forces the development team to work together rather than separately.

Daily Stand Up Meeting

Daily Scrum stations are held for no more than 15 minutes each day of the Sprint. At the daily Scrum station, the development team reviews what was accomplished in the previous day and makes a plan for the day ahead. If there are details that need to be discussed in detail, the development team or development team members usually get together immediately after the daily Scrum station to discuss them in more detail, or to adjust or replan the rest of the Sprint.

Goal:

  • View progress towards achieving Sprint goals, and view progress trends towards completing the Sprint to-do list.
  • Enhance communication
  • Identify obstacles that need to be removed during development
  • Improve awareness of the development team

The Scrum Master is responsible for ensuring that the development team’s daily station meetings are held as scheduled, but the development team is responsible for holding their own meetings. Scrum Masters teach development teams to limit daily Scrum meetings to 15 minutes. The daily Scrum station will be an internal meeting of the development team. If someone from outside the development team is present, the Scrum Master must ensure that they do not interfere with the meeting.

Review Meeting

A Review Meeting is a Review Meeting, usually at the end of the Sprint, to Review the incremental Product delivered and adjust the Product Backlog as needed. During the Sprint review meeting, the Scrum team and stakeholders synchronize the completion status with changes to the product backlog during the Sprint, and all participants discuss what might be done next.

Sprint Review Meeting:

  • The product owner invites the Scrum team and key stakeholders to the meeting;
  • The product owner states which product backlog items are “done” and which are not;
  • The development team discusses what went well during the Sprint, what problems were encountered, and how they were resolved;
  • The development team demonstrates the “done” work and answers questions about delivered increments;
  • The product owner discusses the current status of the product backlog;
  • All the participants discuss the next step of work;

Restrospective Meeting

The restromeeting is the Scrum team’s chance to examine themselves and create an improvement plan for the next Sprint.

Timing:

The retrospective meeting occurs after the Sprint review meeting and before the next Sprint planning meeting.

Length:

For a one-month Sprint, retrospective sessions are limited to three hours. For shorter sprints, meeting times are usually shorter.

Objective:

  • Review what happened in the previous Sprint about people, relationships, processes, and tools;
  • Identify and rank the main areas that are doing well and potentially need improvement;
  • Develop plans to improve the way Scrum teams work;

Responsibilities of Scrum Master:

The Scrum Master ensures that the meeting takes place and that the purpose of the meeting is understood by everyone involved, and that the rules of the time box are taught along the way. The Scrum Master needs to encourage the Scrum team to improve development processes and practices within the Process framework of Scrum so that the team can be more productive and enjoyable in the next Sprint.

There is no limit to the form of restromeeting. One can choose one by oneself.

Stern said

These are the main events of Scrum, which you will need to follow in a real project. An effective Scrum team needs everyone to adhere to the values of Scrum to be sustainable. Scrum is practiced successfully when the team practices the five values of commitment, courage, focus, openness, and respect and trust each other.

Hopefully, everyone who reads this article will have some understanding of Scrum.

Reference Database:

The scrum Chinese website: www.scrumcn.com/agile/scrum… The above pictures are from the Internet.