Scrum is a framework for developing, delivering, and sustaining complex products through effective team collaboration. It provides a lightweight process to focus and coordinate collaborative, team-based activity as the Scrum Team addresses complicated adaptive problems and delivers a product of optimum value incrementally and to a predictable schedule.

Originally conceived by professors Hirotaka Takeuchi and Ikujiro Nonaka and published as “The New Product Development Game” in the Harvard Business review in 1986, Scrum was adapted and popularised by Jeff Sutherland and Ken Schwaber in the 1990s. It has become an increasingly popular way of working, expanding out of software development into many areas of product development that can apply and benefit from an iterative and incremental approach. It succeeds or fails on the technical competence and collaborative efforts of the team.

From a process perspective Scrum offers a simple and extremely effective agile approach to product delivery. As will be shown later, Scrum is not, and is not intended to describe an agile approach to project management.  

The framework includes three distinct roles that make up a Scrum Team, each with clearly defined accountabilities, five events, and three artifacts. The rules outlined in The Scrum Guide bind together the roles, events, and artifacts, guiding their relationships and interactions.

• The 5 Events: The Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective
• The 3 Artifacts: Product Backlog, Sprint Backlog, Product Increment
• The 3 Roles: Product Owner, Developer, Scrum Master.

1. The Sprint is a time-box, which can be any duration but is typically 2 to 4 weeks, during  which one or more “Done” (i.e. useable, and at least potentially releasable) Product Increments are created. The Sprint contains all the other events.
2. Sprint Planning is where the work to be performed in the next Sprint is planned by the Developers. They negotiate a realistic Sprint Goal with the Product Owner, select appropriate items from the Product Backlog to contribute to that goal and plan the work to achieve it.
3. The Daily Scrum is a 15-minute meeting held by the Developers in the Scrum Team. It is held every day of the Sprint and the Developers use it to reaffirm their commitment to achieving the Sprint Goal and adjust their plans accordingly.
4. The Sprint Review is held at the end of the Sprint. Its purpose is to make visible to stakeholders what has been delivered in the Sprint, to allow them to formally inspect and suggest adaptations to the Product Backlog to guide ongoing development.
5. The Sprint Retrospective is an opportunity for the Scrum Team to reflect on the effectiveness of their way of working and create a plan for improvements to be enacted during the next or subsequent Sprints.

Scrum’s three artefacts are designed to maintain a focus on the value to be delivered. They are transparent – i.e. deliberately visible – to anybody who is interested in what the Scrum Team is doing and how they are going about their work. Each artefact includes a commitment.

The Product Backlog is an ordered list of everything that needs to be done to achieve its Product Goal. It is the single source of work for the Scrum Team. While there may be more than one Product Goal, for example describing a product roadmap, only one goal at a time is worked on. The Product Goal is the objective, the commitment, that the Product Backlog is designed to achieve.

The Sprint Backlog includes the set of Product Backlog items selected for a Sprint and all the work needed to achieve the Sprint Goal. While one or more Product Increments may be delivered during the Sprint there is only one Sprint Goal. The Sprint goal is the commitment for the Sprint Backlog and is what the Developers strive to achieve.

The Product Increment is what the developers create that meets the need described by one or more product backlog items. It is a tangible step towards achieving the Sprint Goal. When more than one is delivered in a Sprint, each Product Increment includes the previous one. The commitment is to achieve the 'Definition of Done' for the Product Increment. This 'Definition of Done' is a formal description of the necessary quality standards the product must meet.

We know from the Agile manifesto that practitioners of agility value individuals and interactions over processes and tools – meaning that while there is a place for processes and tools – and let’s be very clear, Scrum includes a significant process element to it – we value people and the way they work together, more. The roles and accountabilities associated with those roles as well as the collaborative interactions between the individuals who hold those roles is fundamental for the effective use of Scrum.

A Scrum Team is made up of one Product Owner, one Scrum Master and, typically, between 5 and 9 Developers. The team needs to be cross-functional – collectively having all the competencies needed to deliver the desired product and the ability to collaborate to achieve that objective. The team is self-organising – recognising no hierarchical structure and allowing leadership for specific work to emerge as appropriate.

Product Owner

The Product Owner is accountable for maximising the value of the product resulting from the work of the Scrum Team. The Product Owner is an individual, not a committee and typically represents the needs of many stakeholders, including the customers for whom the value is being created. In contributing to the work of the Scrum Team, they are accountable for effective Product Backlog management, which includes:

• Developing and explicitly communicating the Product Goal.
• Creating and clearly communicating Product Backlog items.
• Prioritising Product Backlog items.
• Ensuring that the Product Backlog is transparent, visible and understood.

Any stakeholder wanting to change the Product Backlog can do so only through the Product Owner.

Developer

The Developer role in the Scrum Team applies to anybody who is actively collaborating with others in the team to develop the Product – even somebody who also holds one of the other roles can be a Developer.   The skills needed by a Developer will vary depending on the type of work being performed and what is being produced.  Developers working in a Scrum Team to landscape a garden will need a very different skill set to those preparing an elaborate dinner party or those building a new game for a smartphone. Scrum can be applied in all these development environments.

In Scrum, Developers are always accountable 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.

Scrum Master

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organisation.

Often referred to as a servant leader, the Scrum master holds no command authority – they don’t tell people what to do and how to behave, they help them understand how Scrum should work and do what they can to facilitate its adoption. They provide a service to:

• The Scrum Team – coaching their Scrum adoption, helping them find ways of continually improving the way they deliver value and causing removal of anything that gets in the way of this.
• The Product Owner – helping them with Product Backlog management and helping them ensure that Product Goals and Product Backlog items are properly shaped, expressed and understood.
• The wider organisation in which the Scrum Team exists – helping them understand the Scrum way of working and how they need to work and behave to allow Scrum Teams to be optimally effective. 

The Scrum framework is underpinned by the theory of empirical process control, or empiricism, which maintains that knowledge comes from experience and decision-making is based on what can be observed. The pillars of empirical process control are transparency of process and progress, inspection of process and progress and adaptation of both the emerging product (making it better with each iteration and increment) and ways of working (continually improving team effectiveness and performance).

It is important to understand how to make the empirical process effective. Transparency enables Inspection, Inspection enables Adaptation and Adaptations must be Transparent. Inspection without Transparency is misleading and wasteful, Inspection without an intention for Adaptation is pointless and Adaptation without Transparency to Inspect its impact makes Adaptation risky.

Effective Scrum teams live and breathe a set of five values. These values are not unique to a Scrum team, but by making them explicit they encourage effective, collaborative team-based working. The values are Commitment, Focus, Openness, Respect and Courage.

• Commitment: Scrum Team members are committed to achieving sprint goals and delivering high-quality work through iterative development and incremental delivery. This fosters responsibility and accountability among team members.
• Courage: Scrum Team members have the courage to openly address challenges and impediments. They are willing to take risks and speak up about issues that may affect the team’s success.
• Openness: Scrum Team members share information, progress, and concerns amongst themselves, thereby fostering trust and collaboration within the team.
• Focus: Scrum Team members maintain a collective focus on Product and Sprint Goals, prioritising their work to optimise their delivery of value.
• Respect: Scrum Team members respect each other as professionals acknowledging each other’s skills, perspectives, and contributions as they go about delivering the product. This creates a positive work environment and enhances cooperation among team members.

These values can and should be applied to help make any agile way of working effective.

The Scrum values collectively contribute to the Scrum team's ability to:

• Adapt to Change: Scrum is highly responsive to changing requirements. It accommodates evolving customer needs by enabling adjustments at the end of each sprint, promoting flexibility and greater customer satisfaction.
• Collaborate to make decisions: The self-organising nature of the Scrum Team and the empirical underpinning of the Scrum way of working encourages collaboration. Living the Scrum values brings collaborative working to life.  
• Continuously Improve: Scrum incorporates regular retrospectives – the purpose of which is to provide regular opportunities for the Scrum Team to inspect the effectiveness of the way they work and identify areas for improvement. This is continuous improvement in action.
• Embrace a Customer-Centric Approach: Scrum places a strong emphasis on delivering value to the customer. The Product Owner, representing customer interests, prioritises features, ensuring that the product aligns with customer needs and expectations throughout its development.

Scrum offers numerous benefits for product development, enhancing efficiency, collaboration, and adaptability:

• Flexibility
• Faster Time to Market
• Enhanced Collaboration
• Improved Product Quality
• Increased Customer Satisfaction
• Higher Productivity
• Better Risk Management
• Transparency
• Empowered Teams
• Continuous Improvement.

Discover more about the 10 key advantages of using Scrum, elaborated on in this blog.

Scrum, can present several challenges and drawbacks. When implementing Scrum, as with all new ways of working, there may be resistance to change. Teams can struggle with the level of collaboration and communication needed for Scrum to work effectively. Roles like the Scrum Master also have specific responsibilities that differ from traditional roles, and misunderstanding these roles can lead to confusion and inefficiency. Once Scrum is implemented, there are still challenges to be faced, common risks or drawbacks include:-

1. Inadequate Management Support: As for any change initiative without strong support from management within the organisation, the adoption of Scrum will encounter resistance or face challenges in overcoming organisational barriers. Lack of understanding of the cultural change needed and weak commitment to this at higher levels can severely limit the value that Scrum can deliver as a way of working.
2. Learning Curve: Initial disruptions and adjustments may impact productivity as team members adapt to the new roles, events, and collaborative processes introduced by Scrum. The adage that things may get worse before they get better is often true. The key is to allow time for learning and to identify people with a track record of making this work elsewhere who can help.
3. Overcommitment:  Teams may face the risk of overcommitting to work during sprint planning, leading to burnout or compromise in the quality of deliverables. Balancing the desire for rapid progress with realistic goal setting is crucial to maintaining sustainable development practices. It is important to establish a sustainable pace – expect failure to achieve Sprint Goals while the team work out what can be achieved.
4. Overemphasis on Short-Term Goals: The focus on short, fixed-length sprints in Scrum can sometimes lead to a myopic view, where teams prioritise immediate goals over long-term strategic objectives. In a pure product environment, a good Product Owner should be able to communicate and maintain an appropriate long-term focus. When challenged by complexity something more may be needed…
5. Issues integrating the work of multiple teams for bigger, more complex endeavours: Scrum is strong when applied to single teams but extremely weak when the work to be done exceeds the capacity of the ‘10 or fewer’ people in the team to achieve it. In this circumstance, a broader framework to deal with scale and/or complexity is recommended.

For extreme scale in a product context – where hundreds of developers are needed – a scaled framework such as SAFe may be advisable. For smaller scale problems – up to 100 developers, for example – and/or where the complexity of the overall business solution spans multiple products, services and other activities then an agile project framework such as AgilePM will meet the need.  

Building on the scaling issue mentioned above, in this episode of APMG's ‘Level Up’ series, agile project management experts answer questions about agile project management and scrum. One of the key questions addressed is the difference between these approaches.  Issues such as sprint planning, the ideal length of a Sprint and the value of daily stand-ups are discussed.

The Agile Business Consortium has evolved their world-leading Agile Project Management approach (AgilePM) to provide a version designed specifically to work with Scrum. AgilePM for Scrum offers a single framework for the delivery of complete business solutions. It deals explicitly with solutions that encompass multiple products or services, requiring the combined development effort of multiple scrum teams, or a combination of scrum and non-scrum teams. With techniques to deal with agile cross-team planning and coordination, leadership from the perspectives of business vision, solution architecture and project management, governance, risk, and more this is well worth considering for that more complex project situation.

In this video, Richard Pharro, CEO of APMG International, and myself discuss ‘AgilePM for Scrum.' This new framework merges the strengths of two leading Agile frameworks. Richard asks key questions, aiming to provide insights into the framework, including its scope, the rationale behind its development, and who stands to benefit most from the framework. Additionally, we explore the accredited training and certification program supporting this framework.

Scrum has blazed a significant trail for agility in software product development and is a very popular and versatile approach for good reason, being a perfect fit for delivering products that delight customers in the face of complex and evolving requirements. It leverages the advantages of cross-functional, collaborative teams to deliver value more quickly and efficiently than their less agile counterparts.

It is not without its challenges, though... Ken Schwaber and Jeff Sutherland state in their Scrum Guide 2020 that “The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety…”

Scrum is a simple, elegant, effective agile framework for product delivery. This has been proven time and time again all over the world in many different applications across many different industries, but only when used in its entirety. If you leave any element of Scrum out, it simply won’t work properly. Scrum works, ScrumBut risks failure. ScrumBut describes a situation where “we use Scrum but we don’t do this”.  For ‘we don’t do this’ insert anything you like… “We don’t do a daily Scrum”, “we don’t collaborate”, “we don’t have a Scrum Master we have a manager”, “we don’t have a product backlog, we have a spec”, “we don’t define a Sprint Goal” etc. Schwaber and Sutherland developed Scrum, have overseen its gradual and careful evolution since the mid 1990s – accept their wisdom and do it properly.  

If your game is product development, then it is easy to see how bringing agility to that game by applying and continually improving the application of Scrum could provide tremendous benefit. But if your concern runs wider than pure product development then, stand-alone, Scrum may prove inadequate.

Training, education and ongoing encouragement and support of Scrum Teams is needed to leverage success of Scrum. APMG offer the following certifications for the key roles.

This course teaches you to excel as a Scrum Master, enhancing product and solution development using Scrum. Key learnings include a comprehensive understanding of the Scrum Framework, Scrum principles, and the Scrum Master role. You will also learn how to build effective development teams, act as a servant-leader, facilitate Scrum events, aid Product Owners in backlog management, and drive Scrum adoption.

On this course learn how to maximise the value of products delivered by Scrum Teams. Gain a deep understanding of the Scrum Framework and the role of the Scrum Product Owner. Master the Scrum principles and how to build and prioritise a value-driven product backlog, breaking down epics and themes into actionable user stories.

The first day of both the Scrum Master and Product Owner courses are identical – speak to your APMG training provider about delivery of this day as a stand-alone course ideal for team members and stakeholders. It covers everything in the Scrum Guide – and they need to know it all.   

AgilePM for Scrum combines Scrum with the world’s leading agile project management approach (AgilePM) to offer a single framework for the delivery of complete business solutions where iterative and incremental development is required. This certification equips you with the skills to integrate Scrum with Agile Project Management. The courses address the principles and theory underpinning the Scrum framework – delivered by APMG and Agile Business Consortium accredited providers.

The image of the 'Scrum Framework' was created by the Agile Business Consortium. Copyright © 2024, Agile Business Consortium. All rights reserved.