What Does Scrum Stand For?

The simplest definition of Scrum is that it is a framework for Agile software development. The term “scrum” was first used by Hirotaka Takeuchi and Ikujiro Nonaka in their paper titled “The New New Product Development Game.” They borrowed it from the game of rugby, where scrum is a formation of players that emphasizes the importance of teamwork. In that paper (published in the Harvard Business Review in 1986), the authors compared cross-functional, high-performing product development teams to rugby teams that use the scrum formation every time they restart their play. Since it relies on the same principles for developing and sustaining complex products, the Scrum development method inherited its name from this paper.

The underlying principles of scrum include self-organizing teams, creating releasable products, and timeboxing of work. Takeuchi and Nonaka considered their concept of “scrum” as the core of any system that strives to be lean. Still, they never wanted to use the term “lean” because it is synonymous with an outside interpretation.

Scrum is one of the most utilized frameworks for Agile product delivery and it wasn’t meant only for software product development but for complex product development in general. Takeuchi and Nonaka noticed that small and self-organizing teams of people fed with challenging objectives (not executable tasks) could achieve outstanding performance.

What Does Scrum Stand For?

Scrum is a type of agile development method used by many companies across the world. It exists to change the way software development teams handle complex projects, bringing the Agile principles and Scrum framework beyond software development to the broader world of work. Originally, Scrum was created for software development projects, but it works excellent for any innovative, complex scope of work.

What makes the Scrum framework?

• The Product Owner creates a prioritized wishlist called a product backlog.
• During sprint planning, the team pulls a chunk from the top of the backlog, and that chunk is called the sprint backlog. Together, team members decide how to implement it within the sprint timeframe.
• The team has 2 to 4 weeks to complete the work of the given sprint. They meet each day to discuss their progress, and those daily meetings are called Daily Scrums.
• The Scrum Master is there to keep the team focused on their objectives.
• At the end of each sprint, their work should be deliverable – ready to show to a stakeholder, put on a store shelf, or hand to a customer. Each sprint ends with a sprint retrospective and review.
• At the beginning of the next sprint, the team chooses another sprint backlog and starts working again.

This cycle will keep repeating until every product backlog item has been finished, a deadline arrives, and the budget is depleted. Which of those milestones marks the end of the work is specific to the project. Regardless of what stops the work, the Scrum approach ensures that the most important and valuable work has been finished before the project’s end.

Core Values

Scrum’s core values and principles represent the foundation for all the work performed. Since it emphasizes continuous improvement and teamwork, Scrum both creates its values and relies on them. Scrum’s values include:

• Focus. Team members produce excellent work and work well together because they focus on a few things at a time. This enables them to deliver valuable viable products sooner.
• Respect. As they work together, team members come to respect each other as well as help each other become worthy of respect.
• Openness. As they work together, team members practice communicating about how they are doing and what issues they encounter. They learn that it’s best to express their concerns on time so they can be fixed as soon as possible.
• Courage. Team members get the courage to tackle greater challenges from having each other’s support and plenty of resources at their disposal.
• Commitment. Team members are more committed to success because they have great control over their work and destiny.

The Three Pillars of Scrum

Scrum is globally recognized and the most widely adopted of all Agile frameworks because it’s ideal for completing any innovative work and complex project scope. Therefore, everything depends on how Scrum is implemented and not in what industry. Even though it’s mostly used in the IT sector, Scrum’s principles and processes can be applied to almost anything (as long as organizations adhere to its incremental approach to control risk and optimize predictability).

Transparency, inspection, and adaptation are the three pillars Scrum was built on, and they are critical to making Scrum work for your organization.

• Transparency

Team members talk about the setbacks in their work and the transparent backlogs because of the consistent use of inspect-and-adapt events at the end of each PI (Program Increment). Transparency is essential because it enables continuous improvement and a shared understanding of the Scrum approach.

• Inspection

The Scrum team inspects their progress towards the goal and the items they’re creating, which includes showing the product to stakeholders and the product owner at the end of the sprint.

• Adaptation

Whenever the team comes across any impediments, they can adapt their way of working to address or work around the issue. Probably the biggest reason companies decide to work through Scrum is the process of continuous improvement over time and improved ability to adapt.

With these three pillars in mind, we can conclude that the Scrum approach to project management is all about the value delivered to clients. It enables the organization to adapt to the new environments and situations as well as change product requirements during product development. This adaptability and agility enable Scrum teams to build a product of high value to the clients.

Scrum Events

The Sprint can be defined as a timebox of two to four weeks during which the team builds a potentially deliverable product increment. Typical characteristics of Sprints are:

• Maintain a consistent duration throughout the development process.
• The conclusion of the previous Sprint is immediately followed by a new Sprint.
• Start and end dates of each Sprint are fixed.

Sprint planning is a discussion during which team members determine which items from the product backlog they’ll work on during the Sprint. The Sprint Backlog is the end-result of Sprint Planning. Sprint Planning meetings usually consist of two parts. In the first part, the team and the Product Owner agree on which items from the product backlog will be included in the Sprint. In the second part, the team determines how they will deliver these product backlog items as part of the deliverable product increment (they may identify specific tasks necessary to make it happen). Once the Product Owner and the rest of the team establish the scope of the Sprint as described by the backlog items, they cannot add more items to the Sprint Backlog. This is a way to protect the team from scope changes within a Sprint.

Daily Scrum is a short, 15-minute meeting or discussion where the team members coordinate their activities for the day. It is not intended to be a problem-solving discussion or a status report meeting. The development team members are the mandatory participants at the Daily Scrum. The attendance of the Scrum Master and Product owner is optional.

Sprint Review. Sprint Reviews occur at the end of each Sprint. Scrum development teams and the Product Owner meet to review the results of the Sprint along with product stakeholders. They discuss what was completed and adapt the Product Backlog based on the feedback. The purpose of this review is to demonstrate, discuss, and potentially give the stakeholders a chance to use the increment (so they’re able to provide their feedback). The Sprint Review isn’t intended to provide a status report.

Sprint Retrospective. Sprint Reviews put the focus on the product, while Sprint Retrospectives take a look back at the process. During a Sprint Retrospective, the team talks about areas for improvement and what went right in the Sprint. They develop plans for ways to improve their tools, processes, and relationships. The development team and Scrum Master must attend the Sprint Retrospective, while Product Owners are mandatory attendees. These discussions are limited to a maximum of three hours (about 45 minutes for each week of sprint length).

Conclusion

The Scrum framework is simple, and the Scrum artifact roles, rules, and events are easy to understand. Scrum project management approach has a semi-prescriptive approach that helps remove any ambiguities in the development process, while leaving enough space for organizations to add their unique flavor. If your team is used to the traditional waterfall model, they will need expert training services to master the concepts of smaller iterations, Daily Scrums, Sprint Reviews and Retrospectives, and identifying a Scrum Master. All of this could be a challenging cultural shift for your team.