Scrum

parler de logique et de biais cognitif

The Role of Judgment in Decision-Making

Ultimately, all decisions and policies are based on judgment; there is no other method, and there never will be. No matter how in-depth the analysis, it remains only a tool to aid the decision-maker’s judgment and intuition. These principles apply to both project management and systems management.

The Systems Approach: A Problem-Solving Method

The systems approach can be defined as a logical and disciplined process for problem-solving. The term process indicates an active and evolving system, driven by input from its various components.

The systems approach:

• Encourages a reevaluation of the relationships between different subsystems

• Is a dynamic process that integrates all activities into a coherent overall system

• Methodically assembles and coordinates system components into a unified whole

• Seeks an optimal solution or strategy to solve a problem

Development Phases of the Systems Approach

The systems approach follows development phases similar to those of the traditional life cycle. These phases are defined as follows:

• Translation: Definition and mutual acceptance of the terminology, problem objectives, criteria, and constraints by all participants.

• Analysis: Identification of all possible approaches or alternatives to solve the problem.

• Trade-off: Selection criteria and constraints are applied to identify the most suitable alternative.

• Synthesis: The combination of the analysis and trade-off phases results in the best solution for achieving the system’s objective.

Key Elements of the Systems Approach

Other essential concepts in the systems approach include:

• Objective: The system’s function or the strategy that must be achieved.

• Requirement: A partial need necessary to fulfill the objective.

• Alternative: One of the selected ways to implement and satisfy a requirement.

• Selection Criteria: Performance factors used to evaluate and choose between alternatives.

• Constraint: An absolute factor defining the conditions that alternatives must meet.

The Limitations of Subjective Thinking in Decision-Making

A common issue among certain potential decision-makers (those with the authority to act but who are dissatisfied with existing solutions) is that they base their reasoning solely on subjective experience, judgment, and intuition. This can lead them to overlook the existence of viable alternatives.

Subjective thinking is often influenced by personal biases, which can hinder effective decision-making.

Objectivity: A Key Principle of the Systems Approach

Conversely, objective thinking is a fundamental characteristic of the systems approach. It is demonstrated by the tendency to analyze events, phenomena, and ideas externally, independently of personal consciousness.

Objective thinking is unbiased and impartial, making it essential for effective decision-making.

The Systems Analysis Process

As illustrated in Figure, the systems analysis process begins with a systematic examination and comparison of different alternatives, aligned with the desired objective.

These alternatives are then evaluated based on their costs and associated benefits. The loop is closed with feedback, which assesses how well each alternative aligns with the organization’s objectives.

Key Steps in Systems Analysis

The systems analysis process can be structured into several steps:

1. Input data into the mental process

2. Analyze data

3. Predict possible outcomes

4. Evaluate outcomes and compare alternatives

5. Choose the best alternative

6. Implement the chosen alternative

7. Measure results and compare them with predictions

The Importance of Preparing for Alternatives

The systems approach is most effective when individuals are trained to anticipate multiple alternatives, directly linked to predicting outcomes.

The fundamental tool of this approach is the outcome array, which represents all possible circumstances. This tool can only be developed if the decision-maker considers a wide range of potential outcomes.

Clearly defining expected outcomes forces the decision-maker to clarify their objectives, allowing for more effective decision-making.

Systems Thinking: A Key Asset for Project Management

Systems thinking is essential to project success.

Project management systems urgently require new strategic approaches that enable:

• Reevaluating and questioning project needs

• Analyzing technical and non-technical alternatives

The ability to analyze the entire project, rather than just its individual components, is crucial for successful project management.

Software development is a complex process.

Software is built on volatile foundations: often unclear user requirements, interaction with other software, and above all, collaboration between humans, the most complex organisms on the planet.

Scrum: An Approach to Master Complexity

Scrum was designed to extract usable products from complex problems. For the past 10 years, this method has been successfully applied to thousands of projects across hundreds of organizations.

Two types of process control exist:

1. Defined process control: Suitable for well-understood and repeatable processes, where results can be precisely predicted. This isn't really Scrum. For example: Automotive Production Line 🚗

2. Empirical process control: Used when the complexity of intermediate activities makes defined control inapplicable.

The empirical process control relies on three fundamental pillars:

• Visibility: Elements influencing the outcome must be visible and understandable.

• Inspection: The process must be frequently inspected to detect variations.

• Adaptation: When variations occur, the process must be quickly adjusted.

Example: Code review is an empirical process: code is evaluated by experienced developers who suggest improvements and adjustments.

Software development is inherently complex, with three major complexity factors:

1. Requirements: They are often unclear, evolving, and poorly defined.

2. Technology: Software is built with advanced and interconnected technologies, sometimes unreliable.

3. People: Each developer has a different level of experience, vision, and mindset, which further complicates project management.

Scrum is designed to manage this complexity by integrating inspection, adaptation, and visibility.

Scrum is based on an iterative and incremental framework:

• Each Sprint (iteration) produces a functional deliverable.

• Each day, a Daily Scrum inspection allows progress evaluation and plan adaptation.

• This cycle continues until the project is no longer funded.

The heart of Scrum is this ability to continuously adapt to project challenges.

Scrum defines three main roles:

1. The Product Owner

• Defines requirements in the Product Backlog.

• Prioritizes features to be developed.

• Ensures maximizing return on investment (ROI).

2. The Development Team

• Autonomous, self-organizing, and cross-functional.

• Transforms the Product Backlog into usable features.

• Responsible for Sprint and project success.

3. The ScrumMaster

• Ensures Scrum is properly applied.

• Protects the team from external interruptions.

• Facilitates continuous process improvement.

Scrum distinguishes between committed participants ("pigs") and observers ("chickens") to avoid unnecessary interference.

The ScrumMaster plays a key role by providing leadership, guidance, and coaching. They are responsible for teaching teams how to use Scrum to manage the complexity inherent in each project.

In software development, complexity is omnipresent, and there are no silver bullets: success relies on hard work, intelligence, and courage.

Controlling a Complex Process through Empirical Methods

Scrum is based on empirical process control, an approach that allows managing software projects without guaranteeing an exact outcome, but by guiding work towards the best possible value.

Complex problems are unpredictable, and even their way of being unpredictable is unpredictable.

1. Product Vision: The Product Owner defines market needs.

2. Product Backlog: List of features to be developed.

3. Sprint Planning: Selection of priority tasks for the Sprint.

4. Daily Scrum: Daily synchronization meeting.

5. Sprint Review: Demonstration of developed features.

6. Sprint Retrospective: Process analysis and improvement.

Scrum introduces key tools to structure the project:

• Product Backlog: Evolving list of project features.

• Sprint Backlog: List of tasks to be completed in a Sprint.

• Burndown Chart: Graph showing work progress.

The goal is to make the project visible and transparent for everyone.

In Scrum, there is no official role of “Project Manager” as found in traditional methodologies (e.g., PMBOK or Prince2). However, some responsibilities of a project manager are distributed among various Scrum roles.

1. Official Roles in Scrum

Scrum defines three key roles:

1️⃣ The Product Owner (PO) → Responsible for the product vision and backlog

2️⃣ The Scrum Master (SM) → Facilitator of the Scrum process, team coach

3️⃣ The Development Team → The members who build the product

📌 None of these roles directly correspond to a traditional Project Manager.

2. Who Takes on the Project Manager’s Responsibilities in Scrum?

📌 The Scrum Master is not a project manager but rather a coach and facilitator. Unlike a traditional Project Manager, they do not make decisions for the team.

3. Can There Be a Project Manager Alongside a Scrum Master?

🔹 In pure Scrum, a Project Manager is not necessary because their responsibilities are already distributed.

🔹 However, in large organizations or complex projects, a Project Manager may exist to:

💡 In such cases, the Project Manager complements the Scrum Master and Product Owner without interfering with Scrum.

Management Roles in Scrum

In Scrum, the world is divided into pigs and chickens. Pigs are those directly involved in the project: the Product Owner, the ScrumMaster, and the Team. Other managers within the organization are chickens, interested in the project but without direct authority over its execution.

Scrum promotes team autonomy and limits external interference. Chickens should not disrupt the work of pigs. For example, an external manager should not impose tasks or modify priorities during an ongoing Sprint.

The ScrumMaster at MetaEco

The ScrumMaster plays a role similar to that of a project manager, but instead of directly managing the work, their goal is to make Scrum work. They ensure the correct application of Scrum practices and meetings and guide the project through complexity. Their role is to keep the team focused and protected from external interruptions.

Situation at MetaEco

MetaEco develops code generation software, but its primary client was acquired by a competitor, putting the company at risk. MetaEco must customize its product for each prospect, which is costly and does not always guarantee a return on investment.

The ScrumMaster in Action

Tom, the CTO of MetaEco, took on the role of ScrumMaster to keep the company on track. He formed two teams: one to enhance the product and another to develop a prototype for a potential client. However, Paul, the CEO, interfered with the team by requesting out-of-Sprint modifications to attract other prospects. Tom reminded him that Scrum prohibits such interruptions during a Sprint but allows priority adjustments during Sprint planning meetings.

The Value of the ScrumMaster

Tom enabled MetaEco to find a balance between development stability and market flexibility. By fulfilling his role as ScrumMaster, he protected the team and helped the company secure an important contract, preventing distractions and ensuring project success.

The Product Owner at MegaEnergy

The Product Owner is responsible for return on investment (ROI). They manage the Product Backlog, prioritize features, and adjust needs based on market changes. Their role is crucial in ensuring the team works on the highest-value elements.

Situation at MegaEnergy

MegaEnergy, a company managing gas pipelines across North America, needed to automate the processing of land royalties paid to landowners. Previous attempts had failed due to complex and outdated procedures, making the process long and expensive.

The Product Owner in Action

Jane, head of the land department, was designated Product Owner. She used the Product Backlog to organize priorities and decided that the first version of the project should automate only land titles from Alberta, a well-known state for the company. In 30 days, a functional first version was delivered, immediately reducing workload by 40%.

The Value of the Product Owner

Thanks to Jane, MegaEnergy achieved a rapid ROI, something that had not been accomplished in previous failed attempts. By being able to regularly adjust priorities, she ensured an efficient and profitable delivery.

The Team at Service1st

Unlike traditional methods where a project manager directs the team, Scrum allows the team to self-organize. The team selects the tasks to accomplish and decides how to execute them.

Situation at Service1st

Service1st, a customer service software provider, wanted some developers to work on the new version while others finished the previous one. A 17-person team was formed, but its size posed an organizational challenge.

The Team in Action

During the Sprint planning meeting, the most active members dominated discussions, leaving the more passive members disengaged. However, the team self-organized into four smaller sub-teams, distributing the work efficiently and autonomously.

The Value of the Team

The team self-organized without external intervention, finding the best way to collaborate. This adaptability is at the core of Scrum, ensuring greater collective efficiency.

Conclusions

At MetaEco, Tom protected the team's productivity by fulfilling his role as ScrumMaster. At MegaEnergy, Jane maximized ROI as Product Owner. At Service1st, the team demonstrated that self-organization is effective.

Scrum provides great visibility into the project’s status, enabling rapid adjustments to meet objectives. The roles of ScrumMaster, Product Owner, and Team are essential in ensuring a balance between autonomy, flexibility, and profitability.

Source: Agile Pain Relief

Aligning Stakeholder Expectations

The Scrum planning process helps set expectations for project stakeholders. These stakeholders include those who fund the project, those who will use the developed features, and those who will be otherwise impacted by the project. The plan ensures that stakeholder expectations align with those of the Scrum team.

For users, the plan helps them organize their work so they can take advantage of new features as soon as they are implemented. For funders, it details the financial needs and the expected timeline for project benefits. The plan also serves as the foundation for project reports.

At the end of each Sprint, stakeholders attend Sprint Review meetings to compare actual progress with forecasts. Any adjustments or modifications made during Sprint Planning meetings are explained. For those unable to attend, project reports compare actual results with the initial plan and any subsequent adjustments.

The Three Essential Questions of Scrum Planning

The Scrum planning process addresses three key questions:

1. What changes can project funders expect upon completion?

2. What progress will be made at the end of each Sprint?

3. Why should funders believe in the project's value and the team’s ability to deliver the expected benefits?

Scrum projects require less upfront planning than traditional projects using Gantt charts. Since these projects are too complex to define entirely at the outset, they are continuously tracked and adjusted to achieve the best possible outcomes.

Product Backlog

Scrum projects require less planning than traditional Gantt-based projects because those working toward the expected benefits provide visibility into their progress at the end of each Sprint. Since Scrum projects are too complex to be fully detailed from the start, they are monitored and guided to ensure the best possible outcomes.

The minimum requirement to start a Scrum project includes a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired final state is.

• For an internal system within an organization, the vision may describe how business operations will be transformed once the system is implemented.

• For a commercial software product, the vision may outline key new features, how they will benefit customers, and their anticipated market impact.

The Product Backlog defines the functional and non-functional requirements that the system must meet to fulfill the vision, prioritizing and estimating them. The backlog is divided into Sprints and potential releases, as illustrated in the following diagrams:

Point Estimation in Scrum

Point estimation is a method for evaluating the effort required to complete a user story or task in a Scrum or Agile backlog.

Detailed Explanation

When you see "Estimation: 5 points", it means the team has assigned 5 effort points to that task or user story.

👉 What do these points represent?

• They are NOT a measure of time (e.g., they do not equal 5 hours or 5 days).

• They represent a relative measure of complexity, effort, and uncertainty compared to other tasks.

• Higher point values indicate tasks that are more complex, longer, or more uncertain.

How Does the Team Assign Points?

Teams typically use the Fibonacci sequence (1, 2, 3, 5, 8, 13…) to estimate effort. This approach avoids overly precise estimates and encourages consideration of task complexity.

Example Scale:

• 1 point → Very simple, minimal effort.

• 3 points → Moderate complexity, manageable effort.

• 5 points → More complex, requires additional work.

• 8 points → Very complex, high uncertainty.

• 13 points or more → Too large to estimate accurately, should be broken down into smaller tasks.

Example Application

If a team estimates “User account creation” at 5 points, it means:

• It is not a trivial task but is feasible within a Sprint.

• It is more challenging than a 2- or 3-point task but less complex than an 8-point task.

• The team considers technical effort and uncertainty when assigning this value.

Why Use Points Instead of Hours?

✔ More flexible: Developers work at different speeds.

✔ Encourages collaboration: The team discusses estimates together.

✔ Better Sprint planning: Teams balance Sprint workloads based on velocity (how many points they can complete in a Sprint).

The Sprint is time-boxed to 30 consecutive calendar days.

• This time frame allows the team to build a meaningful product increment for the Product Owner and stakeholders, while ensuring it is in a potentially shippable state.

• It is also the maximum duration that prevents the team from generating excessive artifacts and documentation to support its work.

• Finally, it is the time limit beyond which stakeholders may lose interest and confidence in the team's progress.

Team Autonomy

✅ The team can seek guidance, help, information, and external support during the Sprint.

🚫 However, no one can give advice, instructions, feedback, or directives to the team during the Sprint.

👉 The team is fully self-managed.

Commitment and Product Backlog Freeze

• The team commits to a selection of Product Backlog items during the Sprint Planning Meeting.

• No modifications to the selected Product Backlog are allowed during the Sprint unles by the pig dev team that can modify tasks

• The Product Backlog is frozen until the end of the Sprint.

Obstacles

• During refinement, and even more during planning, the team sought to reduce risks (de-risk in the 6D pattern). An obstacle is a poorly reduced or ignored risk that has actually occurred. We can't foresee everything!

• For example: Ugo, a developer on the Peetic team, can't push his changes to Git; Alan, the mapping expert, broke his arm skiing during the weekend.

• An obstacle is identified during the sprint execution, as soon as it appears.

• Make obstacles visible on a board. The visibility principle encourages presenting obstacles on a board. They are described by:
  • their status with three columns (identified, being resolved, resolved);
  • their impact (defined by the stories or tasks that are blocked or slowed down);
  • and the date of their discovery.

Resolved obstacles are kept until the end of the sprint: the list of obstacles is useful during the retrospective.

Exogenous Disruption

• In principle, the team is not disturbed during the sprint. The Scrum Master protects it from external interference, in this case from stakeholders. Sometimes a stakeholder makes a request they classify as urgent and the Scrum Master doesn't know how or cannot say no, even though that's the response the team would like to give. It also happens that the disruption is truly urgent, for example a production incident.

• Outside of proven emergencies, two types of exogenous disruptions are identified:
  • forcing the team to do work not coming from the backlog;
  • taking a team member away from the team for some time.

• In both cases, after the disruption, the sprint objective will be re-examined and possibly modified by the team.

• Transparency pushes to put the added work on the sprint board. The occasional removal of a person will have its place in the list of obstacles.

Change Coming from the Team

• A change can come from an opportunity that emerges from the team's work. The team is free to add tasks to the plan, or to remove them.

• Because it happens that tasks are discovered during the sprint: while working on a story, we realize that important work, ignored until then, becomes necessary.

• This is the manifestation of the concept of emergence.

• Regarding a story, as long as it has not been started (it is ready but not in progress), it can be changed or replaced, at the initiative of the Product Owner and in agreement with them. This is the flexibility provided by flow.

Obstacle Management During the Daily Meeting

• It is the responsibility of the Scrum Master to prioritize obstacles and ensure they are eliminated as quickly as possible. Some may be within the team's control, others can only be solved with the intervention of external people, in other teams (for example, if a support team handles the development environment) or with stakeholders who have power.

• An obstacle is identified during sprint execution as soon as it appears.

• The Scrum Master's goal is to have them eliminated. This may require work for the team. If it is not within the team's power, they escalate to the ecosystem level.

Abnormal Sprint Termination

The ScrumMaster can terminate a Sprint early and trigger a new Sprint Planning Meeting in the following cases:

1️⃣ The chosen technology proves to be inadequate or unusable.

2️⃣ Business conditions change, making the Sprint irrelevant for the company.

3️⃣ The team is disrupted by external interference, preventing it from achieving its goals.

The ScrumMaster can make this decision independently or at the request of the team or the Product Owner.

Handling Changes During the Sprint

✅ If the team is unable to complete all committed Product Backlog items, they can consult the Product Owner to decide which items to remove from the Sprint.

⚠️ If too many items need to be removed and the Sprint loses its value, the ScrumMaster may terminate the Sprint early.

✅ If the team progresses faster than expected and can take on additional items, they can consult the Product Owner to determine which Product Backlog items can be added to the Sprint.

Adding Kanban to the Sprint

Adding a Limit on Work in Progress Tasks

• When observing boards, we often notice that there are many tasks in the middle column, in progress. There are more than there are people on the team. Sometimes a single developer has more than half a dozen in progress! Of course, some are sometimes blocked, waiting for an obstacle to be resolved. Nevertheless, in certain circumstances, there are clearly too many tasks in progress.

• An explicit limit on work in progress tasks creates points for discussion and, thereby, improves things. It's a starting point to go further.

Limiting Emergencies

• Sometimes Scrum proves too difficult to follow regarding the aspect of "the team is not disturbed during the sprint." Some organizations that have just switched to Scrum can't manage this. There are always disruptions and the consequence is that the sprint objective is not achieved.

• The proposal is to make the non-disruption rule more flexible by treating emergencies as a flow of changes, at the task level.

• A row for emergencies is added to the task board, explicitly limiting the number of these urgent tasks.

Administrative Responsibilities During the Sprint

📌 Team members have two administrative obligations:

1️⃣ Attend the Daily Scrum Meeting.

2️⃣ Keep the Sprint Backlog updated and publicly accessible.

• The Sprint Backlog must be stored in a public folder on a shared server, visible to everyone.

• New tasks must be added to the Sprint Backlog as soon as they are identified.

• The team must update the estimated remaining hours for each task daily.

Sprint Rules Summary

✅ The Sprint lasts 30 days—no more, no less.

✅ The team is fully autonomous.

✅ The Product Backlog is frozen during the Sprint.

✅ If a Sprint loses its value, it can be terminated.

✅ The team must update the Sprint Backlog in real-time.

👉 Goal: Maximize delivered value while maintaining team flexibility and autonomy. 🚀

Sprint Planning Overview

The Sprint Planning Meeting is time-boxed to 8 hours and consists of two 4-hour segments:

1️⃣ First segment (4 hours): Product Backlog Selection

2️⃣ Second segment (4 hours): Sprint Backlog Preparation

Participants and Organization

The mandatory participants are:

• The ScrumMaster

• The Product Owner

• The Development Team

Guests may be invited to provide specific business or technical insights, but they must leave the meeting once their contribution is complete.

⚠️ Passive observers ("chickens") are not allowed.

The Product Owner must prepare the Product Backlog before the meeting.

👉 If the Product Owner or Product Backlog is unavailable, the ScrumMaster must prepare an adequate Product Backlog and act as a temporary Product Owner.

First Segment: Product Backlog Selection (4 hours)

🎯 Objective:

The Development Team selects the Product Backlog items they believe they can deliver as a potentially shippable product increment.

➡️ At the end of the Sprint, these items will be demonstrated to the Product Owner and stakeholders during the Sprint Review Meeting.

🚀 Process:

• The Development Team may make suggestions, but the final selection of the Product Backlog for the Sprint belongs to the Product Owner.

• The Development Team determines how many Product Backlog items they can realistically complete during the Sprint.

• The 4-hour time limit means that only a quick analysis of the Product Backlog is conducted.

• A more detailed analysis will occur during the Sprint.

• Some high-priority Product Backlog items that are poorly defined may cause issues, making them difficult to complete within the Sprint.

Second Segment: Sprint Backlog Preparation (4 hours)

This segment starts immediately after the first and is also limited to 4 hours.

📌 Role of the Product Owner:

The Product Owner must be available to answer the Development Team’s questions about the Product Backlog.

📌 Role of the Development Team:

• The Development Team is self-organizing and does not accept external instructions on how to transform the Product Backlog into a deliverable product.

• No one else can intervene except to answer specific questions.

🎯 Outcome of the Second Segment:

The Sprint Backlog does not need to be exhaustive, but it must be detailed enough to:

✅ Ensure mutual commitment among all team members

✅ Allow the team to begin work immediately

✅ Evolve throughout the Sprint as new tasks are added

Summary of Key Responsibilities

🔹 Product Owner: Defines what needs to be done and remains available to answer questions.

🔹 Development Team: Defines how the work will be executed and commits to a realistic Sprint Goal.

🔹 ScrumMaster: Ensures that Scrum is followed and that the meeting is efficient.

👉 The ultimate goal of the Sprint Planning Meeting is to ensure that the team knows exactly what they will work on and how they will deliver a usable increment by the end of the Sprint.

The Daily Scrum Meeting is time-boxed to 15 minutes, regardless of the number of team members.

It must be held at the same location and at the same time every working day.

It is recommended to schedule it at the beginning of the day, so that team members start by reflecting on what they did the previous day and what they plan to do today.

Attendance and Punctuality

• All team members are required to attend.

• If a member cannot be physically present, they must:
  • Join via phone or video call
  • Ask another team member to report their status

• Punctuality is mandatory.

• The ScrumMaster starts the meeting on time, regardless of who is present.

• Any latecomer must immediately pay $1 to the ScrumMaster.

Meeting Structure

1- The ScrumMaster starts with the person immediately to their left and proceeds counterclockwise until everyone has spoken.

2- Each team member answers only the following three questions:

Role of the “Chickens” (Observers)

🚫 “Chickens” (observers, stakeholders not involved in development) are not allowed to:

• Speak or intervene

• Make remarks or observations

• Display disruptive facial expressions or gestures

✅ “Chickens” must stand on the periphery of the team to avoid interfering with the meeting.

📌 If too many “chickens” are present, the ScrumMaster can limit their access to maintain order and focus.

⚠️ “Chickens” are not allowed to interact with team members after the meeting to:

• Ask for clarifications

• Give advice or instructions

Penalties for Rule Violations

🚨 Anyone who does not follow the rules may be removed from the meeting:

• Disruptive “chickens” may be banned from attending future Daily Scrums.

• “Pigs” (team members) who fail to comply with the rules may be removed from the team.

Summary of Key Rules

✅ A quick and effective 15-minute meeting.

✅ Team members answer only three questions.

✅ No technical discussions or debates.

✅ No interruptions or side conversations.

✅ Observers (“chickens”) do not interfere.

✅ The ScrumMaster ensures rule compliance and smooth execution.

Sprint Review Meeting Overview

The Sprint Review Meeting is time-boxed to 4 hours.

📌 The team should spend no more than 1 hour preparing for this meeting.

Objective of the Sprint Review

The purpose of the Sprint Review is to allow the team to present completed features to the Product Owner and stakeholders.

📌 Definition of “Done”

• The meaning of “Done” may vary by organization, but it generally means that the feature is fully developed and potentially shippable or deployable.

• If “Done” has a different meaning within the organization, it is critical that the Product Owner and stakeholders understand it.

• 🚫 Incomplete features cannot be presented.

📌 What Can Be Presented

• Only developed features may be shown.

• 🚫 Artifacts (documents, diagrams, schematics, etc.) should not be presented, unless they are used to support the demonstration.

• Artifacts should never be shown as deliverables to avoid stakeholder confusion and prevent them from having to understand technical aspects of development.

📌 Demo Setup

• The demonstration should be conducted on team members’ workstations.

• Execution should be done from the server closest to the production environment (typically a QA server).

Sprint Review Meeting Agenda

1️⃣ Meeting Introduction

• A team member presents:

• The Sprint Goal

• The committed Product Backlog items

• The completed Product Backlog items

2️⃣ Sprint Retrospective Insights

• Different team members share what worked well and what did not during the Sprint.

3️⃣ Feature Demonstration

• The majority of the meeting is dedicated to the presentation of completed features by the team members.

• The team answers stakeholder questions about the demo.

• Stakeholders may request changes or provide feedback.

4️⃣ Stakeholder Feedback Collection

• Each stakeholder is asked one by one to provide:

• Their opinion

• Requested changes

• Priority of these changes

5️⃣ Adjustments to the Product Backlog

• The Product Owner discusses with stakeholders and the team to determine if any Product Backlog adjustments are necessary based on the feedback.

Stakeholder Roles in the Sprint Review

• Stakeholders are encouraged to share their opinions on the presented product increment.

• They can:

• Identify missing or unsatisfactory features and request their addition to the Product Backlog for prioritization.

• Suggest new features inspired by the demo and request their inclusion in the Product Backlog.

Meeting Logistics and Closure

📌 Logistics Preparation

• The ScrumMaster must estimate the expected number of attendees and organize the meeting accordingly.

📌 Closure and Announcement of the Next Sprint Review

• At the end of the Sprint Review, the ScrumMaster announces the date and location of the next Sprint Review Meeting to the Product Owner and stakeholders.

Key Rules Summary

✅ Meeting limited to 4 hours, with a maximum of 1 hour for preparation.

✅ Only completed features are presented—no unnecessary artifacts.

✅ Demo conducted in an environment close to production.

✅ Stakeholder feedback is collected, and the Product Backlog may be adjusted.

✅ The date and location of the next Sprint Review must be announced.

🚀 Goal: Provide stakeholders with visibility, collect feedback, and adjust the Product Backlog to maximize delivered value!

The Sprint Retrospective Meeting is time-boxed to 3 hours.

👥 Participants:

• The Scrum Team

• The ScrumMaster

• The Product Owner (optional)

Retrospective Process

1️⃣ Meeting Kickoff

• Each team member answers two questions:

1. What went well during the last Sprint?

2. What could be improved for the next Sprint?

2️⃣ Note-taking and Prioritization

• The ScrumMaster records the responses in a summary format.

• The team prioritizes the key discussion points among the proposed improvements.

3️⃣ Exploring Improvements

• The ScrumMaster does not provide answers but facilitates the discussion and helps the team identify suitable solutions.

4️⃣ Defining Concrete Actions

• Actionable improvements must be added to the Product Backlog as high-priority non-functional items for the next Sprint.

• 🚨 A retrospective that does not result in concrete changes is ineffective and frustrating.

Key Rules Summary

✅ Meeting limited to 3 hours.

✅ Only the team, the ScrumMaster, and optionally the Product Owner participate.

✅ Analyze what worked well and what needs improvement.

✅ Improvements must be turned into concrete actions in the Product Backlog.

🎯 Objective: Identify what works, what doesn’t, and improve continuously in every Sprint! 🚀

Daily sprint takes 15 min, stand up on the morning

• What did you do yesterday

• what are you doing today

• Do you have any impediments

• The scrum master have to do a review of the sprint progress at the end of the meeting (Burndown chart)

• Keep a schedule of the daily scrum times times on wall + have a recurring appointment in outlook

• Keep to the schedule. Same place, same time (and start even if people are missing)

• Do you update tasks bbefore the Daily Scrum ?

• don’t go into detail

• no phones + no checking email, no distractions

• use a task board (even better use an electronic one)

MegaBank is one of the largest financial institutions in the world. We will examine the use of Scrum at MegaBank here and in the following chapters. Two years after the introduction of Scrum at MegaBank, 20% of all software projects at the bank now use this approach.

One team, having heard about Scrum’s success in other divisions of MegaBank, wanted to experiment with it on a pilot project involving the migration of a MegaBank application from mainframe systems to the Web. The application, called "cash management application", was used to record and report fund transfers. Funding had been approved, the team was assembled, and the plan was written. The team received a memo stating that the web version of the cash management application needed to be completed and ready for implementation within five months. No additional details were required, as the new application was to be an exact replica of its mainframe predecessor; therefore, no new features were allowed for this project.

Sprints typically begin with a one-day planning meeting. However, for projects like this, I add an extra day to build a Product Backlog and train the ScrumMaster, Product Owner, and Team on Scrum principles. I find these two-day sessions particularly effective for teaching Scrum, largely because the subject matter is directly practical, focusing on real work that must be completed in the short term.

Two-Day Sprint Planning Meeting

The team consisted of five developers. The Product Owner, Julie, attended this meeting, as did Tom, the ScrumMaster, and Ed, the head of systems development.

For the first three hours of the meeting, I taught the basics of Scrum – covering the concepts discussed in Chapter 1 of this book. Then, I announced that we were almost ready to start the Sprint Planning Meeting, with one exception: we did not yet have a Product Backlog.

Julie needed a Product Backlog list to identify the highest-priority items. The team also needed to see this list to commit to turning it into a product increment. I reassured them that we would complete the Product Backlog before the end of the day, but that didn’t stop the team members from sighing in frustration.

The developers, in particular, saw this exercise as a waste of time. They asked why we couldn’t just decide what to do for the next Sprint. After all, being agile meant exactly that, in their view.

I explained that we needed a clear project vision within Scrum. The Product Backlog would serve as a reference for defining expectations, allowing MegaBank's management to track the project's progress.

We then posted large sheets of paper on the walls and listed all the features of the existing mainframe system, which had to be fully replicated on the Web. We also considered non-functional requirements, such as setting up QA (quality assurance) and production environments for the system.

In less than two hours, we had listed almost everything for the Product Backlog, at least the most important elements. The rest would emerge as the project progressed. We had enough to get started.

Estimating the Product Backlog

The next step was to estimate the effort required to complete the Product Backlog requirements. Once again, the team sighed in frustration, convinced this task would take forever. They doubted their ability to produce accurate estimates, particularly ones reliable enough to properly set expectations and guide the selection of Product Backlog items for each future Sprint.

Before proceeding with estimation, we discussed the nature of complexity and its impact on software development. To accurately estimate each requirement, we would need to understand its exact structure, its interactions, the technology used, and the skills and mindset of the team members handling the development. We could spend more time analyzing these factors than actually transforming requirements into working software. Worse, even if we succeeded, the very nature of complex problems meant that even small variations in one factor could lead to major and unpredictable changes in how the system evolved.

No matter how much time we spent refining estimates, they would always be fundamentally inaccurate.

After this discussion, I asked Julie and the team to make an initial estimation, keeping in mind this principle: the goal of estimation is to evaluate the relative size of each requirement, both individually and in comparison to other requirements. This information would help us prioritize the Product Backlog and divide it into Sprints.

I reminded them that Scrum is an empirical approach, based on the art of the possible. The team simply needed to do their best in each Sprint, and we would adjust expectations based on actual results. We would track real progress at each Sprint to project the overall project completion. This projection would help us anticipate the release date.

In this case, management expected the system to be ready in five months. Our task was to determine whether this expectation was realistic. At the end of each Sprint, we would update our forecasts by comparing the actual delivered features to the expected ones.

Following these guidelines, the team estimated the entire Product Backlog in just one hour. They based their estimates on their knowledge of the mainframe cash management application, on which all team members had previously worked, as well as their understanding of J2EE, Java, and the new technologies they would be using.

Julie, Tom, Ed, and the team were eager to see whether their estimates aligned with management’s expectations. The key question was: Could the project truly be completed in five months?

What Does “Done” Mean?

Before continuing, I asked the team what factors they had considered in their estimates. Did their estimates include time for analyzing, designing, and coding the Product Backlog requirements? Did they account for unit testing? Were unit tests automated using JUnit? Did the estimates include time for code reviews, refactoring, writing clean and readable code, and removing unnecessary code?

It was crucial for everyone to clearly understand what the estimates covered, to prevent any misunderstanding about when work was truly “done.”

Julie wanted to know why I was emphasizing this point. I explained that the value of a developed feature depends directly on the work done before it is considered complete. For example, if the team skipped unit tests, there would likely be more bugs to fix later. In that case, we would need to allocate more time for application testing before deployment, as there would be more defects to resolve.

Similarly, if the team performed continuous refactoring, the code would be easier to fix, making the application simpler to maintain and enhance.

Julie was unfamiliar with JUnit. A team member explained that it was a tool for creating automated test suites to validate the application. Every time new code was added, the tests ensured that it did not break existing functionality.

Julie was fascinated. She wanted a tested and maintainable application, not just quickly written code. She had always assumed that was what was delivered, but she was happy to clarify her expectations with the team.

I then asked them to re-estimate the entire Product Backlog, considering this new definition of “Done” and Julie’s expectations.

After an hour of discussion about the impact of this approach, the team updated their estimates.

Julie then worked with the team to refine the Product Backlog:

• Which requirements needed to be addressed first?

• Since the QA (quality assurance) team was not part of the Scrum team, which elements could be delivered to QA at the end of each Sprint to start testing?

• Which non-functional requirements should be prioritized?

The result of this collaboration was a prioritized Product Backlog, taking into account new expectations and constraints.

How Difficult It Is to Change

It was time to plan what the team would accomplish during the first Sprint and the ones that followed. We first estimated the average time available per month for each team member. Then, we added up these availabilities to get an approximate idea of how much time the team could dedicate to each Sprint.

Starting from the top of the Product Backlog, we identified how many items could potentially be included in the first Sprint. We continued this exercise, Sprint by Sprint, until the entire Product Backlog was distributed over seven Sprints.

We all leaned back in our chairs. Ed had promised that the team would deliver the system in five months. However, our rough estimates indicated seven months.

No one said it out loud, but we all knew that the new definition of “Done” was the main reason for this two-month delay. If we had stuck to the team’s initial estimates, we probably would have stayed within five months. And if the team had not followed this new definition of “Done”, they might have delivered the system in five months.

But now that Julie understood what “Done” really meant, this additional time was necessary.

I turned to Julie and asked if she wanted us to go back to the old estimates. Julie was outraged.

She wanted to know how we could have committed to five months when we knew it would mean delivering a lower-quality system.

I explained to her that we didn’t know. Until this planning session, we were not in a position to predict whether five months was realistic or not.

However, Ed had promised his management that the project would be completed in five months. Now, he had to tell them that he was wrong.

I told him that this shouldn’t be a problem. After all, Julie was the one paying for the system, and she understood why the estimate had changed from five to seven months.

Besides, we couldn’t be certain of the exact project duration yet. Maybe the team would finish in less than five months… or more. We would have a better idea at the end of the first Sprint.

At that point, we could evaluate the actual speed at which the team was converting the Product Backlog into features and adjust the estimated number of Sprints.

If we wanted to speed up development, we could bring in additional people who were already familiar with the old treasury system. These kinds of options could be discussed at the end of each Sprint.

But Ed was deeply uncomfortable with this approach.

In the past, he always stuck to his initial estimates, and the team had never let him down.

He acknowledged that we now had better information, but MegaBank’s corporate culture dictated that once a five-month estimate was given, that’s all anyone would remember.

Ed then turned to the team and said:

"Look, I know we now have better information, but these are still just estimates. We have five months. You’ve never let me down before, and I’m counting on you not to let me down this time either."

A deep silence followed his statement.

Later, a team member confided in me that he felt like Ed was saying:

"It’s business as usual, Scrum or no Scrum. We can talk about iterations and incremental development, but in the end, we’ll make compromises when necessary."

Ed refused to admit to his management that software development is a complex process and that all estimates are just that—estimates.

Instead, MegaBank’s corporate culture perpetuated the illusion that the future could be predicted with certainty and that estimates should never be adjusted.

The planning meeting had just revealed that, until now, the team had been forced to make compromises to maintain this illusion.

Julie had heard Ed tell the team that meeting the delivery date was more important than quality.

She now knew that he was asking them to do whatever it took to meet the deadline, even if it meant sacrificing quality, despite the fact that she had explicitly requested a high-quality product.

Lessons Learned

Scrum is easy to implement. The cash management project began with the two-day Sprint Planning Meeting described earlier. However, to fully realize the benefits of Scrum, an organization must embrace deep organizational change.

In MegaBank’s treasury project, we encountered a management culture that treated a preliminary estimate as a fixed contract.

Ed was not yet ready to challenge this flawed mindset, but Scrum would provide him, along with Tom, Julie, and the team, new opportunities to do so.

Each Sprint Review would highlight the gap between:

• Initial estimates and actual outcomes

• What the team thought it could achieve and what it actually delivered

At every retrospective, management would have the chance to refine expectations and adjust forecasts more accurately.

At each retrospective, management has the opportunity to refine its expectations and better adjust its forecasts.

We had estimated the cost required to improve product quality by transitioning from "standard" code to tested, clean, and refactored code.

We had also estimated the cost of building a more sustainable and easier-to-maintain system.

However, we had not measured the long-term impact of durability and maintainability.

When Ed asked the team to sacrifice quality to speed up development, what was the real cost to the organization?

How did that cost compare to that of a product designed with a high level of quality from the start?

With this information, Ed might have reconsidered his commitment to management.

Very few projects are sufficiently quantitative to allow for a fully objective decision-making process.

At the end of each Sprint, the Product Owner is responsible for guiding the team toward the work that provides the greatest value to the organization.

This work is not just about turning the Product Backlog into features but also about adhering to engineering practices and standards.

The work has two essential dimensions:

1. The amount of work to be done

2. The expected level of quality

In the next example, we will examine a project that incorporates quantitative data to help make the best possible decisions at the end of each Sprint.

This example is a case study used in Certified ScrumMaster training.

I organize certification sessions to train individuals already familiar with Scrum to become more effective ScrumMasters. We examine how these future ScrumMasters can better fulfill their role within their organization, allowing it to maximize the benefits derived from Scrum.

At the end of each certification session:

• Each participant receives Scrum software and methodological tools to assist them in their role as a ScrumMaster.

• They are also integrated into the ScrumAlliance (www.scrumalliance.org), a community of Certified ScrumMasters.

The certification session is based on team exercises using a case study that illustrates Scrum practices in a practical way.

The case study focuses on the hypothetical launch of a Major League Baseball (MLB) website. This study is detailed in the following sections.

One of the exercises tests the team's ability to engage in constructive dialogue with a demanding client: George Steinbrenner.

Participants must negotiate with Steinbrenner on tough decisions.

At the end of the case study, we present typical team performances from this exercise.

MLBTix

Baseball attendance has increased over the past ten years. In some cities, like Boston, almost every game is sold out, making ticket purchases through regular channels nearly impossible.

MLB rules prohibit the resale of tickets for profit. Illegal ticket scalping is banned and has been subject to increased enforcement in recent times.

The primary distribution channel for purchasing tickets is an online auction site, xAuction.

Although all xAuction sales are supposed to be capped at face value + fees, MLB discovered that, through various loopholes, tickets were being resold for prices reaching 1,000% of the original price.

Project Plan

The MLB Commissioner’s Office hired an external consulting firm, Denture, to plan a project aimed at managing baseball ticket resales. Denture delivered the final plan on November 15, which was subsequently approved.

Project Background

A new law requires that, starting with the 2004 baseball season, all ticket resales must be conducted through MLB-approved platforms.

As a result, MLB decided to develop its own web platform, named MLBTix.

The site will function similarly to xAuction, an online auction platform, but will be specifically dedicated to MLB.

The public will be able to buy and sell MLB tickets online:

• Sellers can auction their tickets, setting a starting price of their choice, with no minimum or maximum limit imposed by MLBTix.

• Sellers can also set the auction duration by specifying a start and end date/time.

• If a ticket is sold, the buyer will pay the seller via the MLBTix payment system, and the seller will then send the ticket to the buyer.

• Once the ticket is received by the buyer, the seller is automatically notified, and MLBTix will send them a check for the sale amount, after deducting MLB’s 25% fee.

Project Timeline

The MLB Commissioner will announce MLBTix during a press conference on January 15.

The goal is to have a first version of the site operational by Opening Day, March 30, 2004, and a fully featured version available before the All-Star Game break, starting July 18, 2004.

Thus, the expected release date is March 30, 2004.

At that time, MLBTix will be live, allowing:

• Buyer and seller registration.

• Fixed-price ticket sales.

• Ticket purchases via credit card.

Tickets will be exchanged directly between sellers and buyers, with MLBTix serving as a facilitator.

Delivery Phases

• June 30, 2004 → Auction system added to the site.

• August 30, 2004 → Additional features:

• Ability to purchase adjacent ticket groups.

• Seat location visualization for tickets on sale.

• Inventory of available tickets.

Constraints and Requirements

• The project budget is sufficient and not a major constraint.

• The top priority is meeting deadlines and delivering the planned features.

• Necessary infrastructure and software to support MLBTix can be purchased or developed, depending on what ensures faster completion.

The Commissioner wants to be informed quickly about the likelihood of MLBTix being ready by the announced dates, before his press conference.

Product Backlog

Functional Requirements

• Clients can register as potential ticket sellers and receive a user ID and password.

• Clients can register as potential ticket buyers and receive a user ID and password.

• Clients can manage a profile associated with their user ID, including:

• Email address

• Postal address

• Preferences

• Credit card information

• Clients can list tickets for auction, defining:

• A starting price

• A start date and time for the auction

• An end date and time for the auction

• Sufficient information for buyers to ensure the tickets meet their needs (correct dates, teams involved, number of adjacent seats, seat locations in the stadium).

• Clients can launch an auction for their tickets, open only to registered buyers.

• Clients can allow MLBTix to automatically conclude the auction, assigning tickets to the highest bidder at the auction's end, immediately charging the buyer's credit card and placing the funds in an MLBTix account.

• MLBTix will notify the seller of a successful sale and provide buyer delivery details.

• MLBTix will offer buyers a mechanism to report that tickets have not been received within the specified timeframe after the sale date (e.g., one week).

• MLBTix will transfer the sale proceeds (minus the 25% MLB fee) to the seller at the end of the delivery period unless the buyer has reported an issue.

• MLBTix will automatically transfer the 25% MLB fee (along with any accrued interest) to an MLB account.

• MLBTix will provide clients with an inventory and a search engine to find tickets based on teams, dates, and available seats.

• MLBTix will support promotional offers on the platform.

• MLBTix will be able to identify and ban users who abuse the service.

Non-Functional Requirements

MLBTix must be able to:

• Handle 250,000 simultaneous users with a response time of less than one second.

• Ensure a high level of security suitable for the expected financial activity (2,000 tickets sold per day at an average price of $50).

• Be scalable to support up to 1,000,000 simultaneous users if necessary.

• Guarantee 99% availability, 24/7.

Development Context for Bidders

The system will be developed in an open-source environment, using Intel technology and an OpenSQL database server.

Development Environment

• All development team members will live close to the development site to facilitate commuting.

• The development site currently has individual cubicles.

• The development environment is wireless and has fully operational electrical and network infrastructures.

• The development environment utilizes open-source tools, including Eclipse.

Development Practices

• The development team is required to use a source code repository.

• Each member must commit their code with every modification.

• The software must be compiled at least once per day.

• Each build must include unit tests and acceptance tests.

• Scrum will be used as the development methodology.

• The adoption of additional Extreme Programming (XP) practices or other engineering practices (e.g., coding standards) is left to the team's discretion.

Team Skills and Requirements

• All developers must have strong software engineering skills.

• Each team member must be familiar with Scrum and Extreme Programming (XP) at a minimum.

• The team should be composed of software engineers with excellent design and programming skills.

• Engineers are responsible for testing and user documentation, though they may hire contractors to assist with these tasks.

• Engineers must have an average of 10 years of progressive experience working on complex software projects using advanced technologies and open-source software.

• All team members must be passionate about baseball.

The Project

Imagine that after a rapid request for proposal (RFP) process, the MLB commissioner has selected your organization to develop MLBTix.

In your RFP response, you assured the commissioner that you would meet the release schedule.

On January 15, you stood alongside the commissioner at a press conference, where he officially announced MLBTix.

During this conference, you demonstrated the functionality developed in the first Sprint.

This first Sprint began on December 7, 2003, and the Sprint Review meeting took place on January 7, 2004.

Your team has just completed its third Sprint, which ended on March 7, 2004.

You have presented the developed features from this Sprint to the commissioner.

Now, all the necessary features for the first release are in place.

You plan to assemble the entire system in the production environment, preparing for the official launch of MLBTix on March 30, 2004, Opening Day of the 2004 MLB season.

Uh-Oh!

During the Sprint Planning Meeting for Sprint 4, your team starts worrying about MLBTix’s ability to handle expected traffic volumes.

MLB has engaged a public relations agency to promote MLBTix, and their work has been almost too effective:

• MLBTix is making headlines in all sports media outlets.

• Every baseball fan now knows about MLBTix and its official launch date: March 30, 2004, at 12:00 PM EST.

• There are over 40 million baseball fans, and no system could handle 40 million simultaneous connections.

Technical Bottleneck Identified

• Load testing has revealed that the application is heavily dependent on database performance.

• Despite all optimization efforts using OpenSQL on the fastest RAID database servers, the system’s maximum capacity with a response time below three seconds is 100 transactions per second.

• Peak traffic is expected during lunch breaks and post-dinner hours.

• The team fears that traffic spikes in full production will overload the server, and that the critical performance limit of 110 transactions per second will be exceeded.

Solution and Impact

• You determine that the Miracle Database could handle the expected traffic load.

• However, replacing OpenSQL with Miracle and fully integrating it would require one additional Sprint.

➡️ As a result, MLBTix would not be ready until a month after Opening Day. 🚨

Your Dilemma: What Do You Tell the Commissioner?

During your presentation, you notice the Commissioner growing more agitated:

• Tapping his foot nervously.

• Spitting on the floor.

• Muttering under his breath.

He is clearly very unhappy.

The Commissioner cuts you off and demands a clear answer.

👉 He wants to know whether he should call his PR team to publicly announce that MLBTix won’t be ready on time.

Lessons Learned: How Teams Respond to This Exercise

I’ve used this exercise in over 10 Certified ScrumMaster training sessions, with participants already familiar with Scrum and experienced in software development.

More than 200 participants, across 40 teams, were asked to formulate their recommendations to the Commissioner.

Key Observations

• Many teams struggled to communicate effectively with the Product Owner (the Commissioner).

• Scrum is based on collaboration, but collaboration requires mutual understanding, which depends on clear communication.

• If the Product Owner speaks only in business terms and the team speaks only in technical terms, there is no real communication.

• Only one out of four teams effectively used financial data to propose clear options to the Commissioner.

How Did the Commissioner Minimize Costs Despite an Expensive Problem?

The issue was that MLBTix risked being unable to handle the expected visitor load at launch, requiring an additional Sprint to integrate a better database (Miracle instead of OpenSQL).

This meant a one-month delay, which was a cost in both time and resources.

However, here’s how the commissioner managed to minimize costs despite this issue:

1️⃣ Avoiding a Catastrophic Failure

• If he had forced the launch on the planned date (March 30, 2004) without addressing the technical issues, the site would have likely crashed under user traffic.

• Consequences:

• A poor experience for fans.

• A damaged reputation for MLB.

• Additional emergency costs to fix the site after the fact (far more expensive than doing it right from the start).

2️⃣ Making a Strategic Financial Decision

• Rather than implementing costly temporary fixes, he opted for a controlled delay to ensure a fully functional site from the beginning.

• Since MLB earns 25% on each ticket sold, a stable and efficient site would generate consistent revenue as soon as it went live.

• A bad launch would have discouraged users and reduced potential revenue, which would have cost even more in the long run.

3️⃣ Limiting Communication Costs

• Rather than announcing a failure and dealing with an expensive PR crisis, he could:

• Communicate a "phased launch" approach.

• Release a controlled beta before full deployment.

• Less panic = less pressure and fewer costs to fix a poorly managed announcement.

Conclusion

The commissioner chose to invest an extra month to avoid much higher costs in the long run.

If MLBTix had launched too early:

❌ Site crash → ❌ Loss of user trust → ❌ Fewer ticket sales → ❌ High costs for emergency fixes

With his strategic decision:

✅ One-month delay → ✅ A stable site → ✅ More long-term sales → ✅ Lower emergency maintenance costs

In essence, he spent a little more now to prevent losing much more later. It was an investment, not a loss.

According to the Scrum Guide, the ideal size of a Scrum team ranges between 3 and 9 members (excluding the Scrum Master and the Product Owner).

A Scrum team is composed of:

If a team becomes too large (more than 9 developers), communication, coordination, and efficiency can be negatively affected. In such cases, it is recommended to split the team into multiple autonomous Scrum teams that collaborate within a scaling framework (such as Scrum@Scale, LeSS, or SAFe).

The Need for Multiple Scrum Teams

Many projects require more effort than a single Scrum team can provide. In such cases, multiple teams may be mobilized. Working in parallel, their efforts are coordinated through various mechanisms, ranging from formal solutions to more informal approaches. When multiple Scrum teams work simultaneously on the same project, it is referred to as a scaled project, and the methods used to organize their work are called scaling mechanisms.

However, it is important to note that scaling is a complex challenge—there are no magic formulas or foolproof methods.

Scaling Scrum becomes necessary when multiple Scrum teams must collaborate on the same project or product. Several frameworks have been designed to facilitate this scaling process, including Scrum@Scale, LeSS, and SAFe. Here is an overview of each:

Scrum@Scale

📌 Developed by Jeff Sutherland (co-creator of Scrum)

• Key Principle: Expanding Scrum while preserving its core values.

• Approach: Scrum@Scale relies on a network of interconnected Scrum teams, where each team operates autonomously but remains aligned through specific roles and events.

• Organization:
  • Scrum of Scrums (SoS): Gathers representatives from each Scrum team to ensure coordination.
  • MetaScrum: Aligns priorities and product vision at the organizational level.
  • Executive Action Team (EAT): Manages and removes organizational impediments.

• Flexibility: Does not impose a rigid hierarchy, allowing organizations to adapt the framework to their structure.

✅ Ideal for: Companies seeking a modular and scalable approach with minimal imposed complexity.

LeSS (Large-Scale Scrum)

📌 Developed by Craig Larman and Bas Vodde

• Key Principle: Keep Scrum “as is” and adapt it to large projects.

• Approach: LeSS is based on the idea that fewer processes and greater simplicity help maintain Scrum’s effectiveness at scale.

• Organization:
  • LeSS (Basic): Up to 8 Scrum teams (maximum of 50 people).
  • LeSS Huge: For very large organizations (more than 8 teams, potentially hundreds of people).
  • All teams share a single Product Backlog.
  • One Product Owner makes strategic decisions.
  • Synchronization is achieved through shared Sprint Reviews and Daily Scrum of Scrums.

• Less hierarchy and a strong focus on inter-team collaboration.

✅ Ideal for: Companies looking for a simple and lightweight approach while avoiding bureaucracy.

SAFe (Scaled Agile Framework)

📌 Developed by Dean Leffingwell

🔹 Key Principle: SAFe combines Scrum, Kanban, DevOps, and Lean to align agility across all levels of a large organization.

🔹 Approach: It provides a structured framework with multiple organizational levels, including:

• Team Level: Standard Scrum teams.

• Program Level: Coordination of multiple teams via Agile Release Trains (ARTs).

• Large Solution Level: For very large projects.

• Portfolio Level: Strategic alignment with business objectives.

🔹 Organization:

• Highly structured framework with well-defined roles, synchronized events, and clear artifacts.

• Emphasizes Program Increment (PI) Planning, which typically lasts 8-12 weeks.

• Integrates Lean Portfolio Management (LPM) to align strategic and budgetary priorities.

🔹 Highly prescriptive and enterprise-oriented.

📌 Ideal for: Large, complex organizations, such as corporations and government agencies, that need a structured framework to manage large-scale agility.

Quick Comparison of Frameworks

After the reading of this text, answer the questions you could find at the end.

Un défi de transformation numérique

We’ve looked at MegaFund in previous chapters. MegaFund had a pressing business problem that it wanted to solve as quickly as possible. If you were a MegaFund customer in 1997 and wanted to transfer money, open an account, trade stock, or take advantage of any of MegaFund’s other financial offerings, you had two choices: you could either pick up the telephone and call an agent or go to the MegaFund office in the nearest metropolitan area and use a dumb 3270-type terminal connected through a network to MegaFund’s mainframes. Although this technology had been innovative in the 1980s, MegaFund competitors now let customers manage their accounts themselves from their home or office computers, cell phones, Web-based devices, pagers, and telephone voice-response units, at any time and on any day. The pressure to correct this competitive disparity and provide competitive technology was immense at MegaFund. Everyone at MegaFund wanted to start his or her own project and immediately build a competitive offering.

Une approche orientée sur l’architecture et l’évolutivité

MegaFund Systems Company (MSC) provided technology services to MegaFund. MSC determined that the best way to support the new competitive products was to link them to its legacy databases through middleware servers. $[10]$ Every organization would write its own business functionality to run on the servers, and MSC would write common data access capabilities. The servers would be designed to support virtually any transaction volumes in a secure, restartable environment. These goals constituted the first nonfunctional requirements that were put in the Product Backlog.
The Product Owner wanted to initiate many teams so that solutions could be delivered as soon as possible. However, if architecture with adequate details wasn’t present first, the work couldn’t be cleanly divided among the multiple teams. If a development environment supporting multi-site source code management and build processes wasn’t set before work began, the multiple Teams would get out of sync and would likely create conflicting code. And if standards weren’t defined before work began, the interfaces between the business and data objects would likely be inconsistent. Consequently, we defined a nonfunctional Product Backlog to devise and construct such a scalability infrastructure. All of these nonfunctional requirements were given top priority.

Mise en place des équipes et première démonstration
We then added a small number of
functional business requirements. The account management organization wanted customers to be able to directly access their accounts and review balances and previous transactions over the Web. We broke these requirements down into smaller pieces and parsed them among the nonfunctional requirements, planning to build part of the account management functionality every Sprint while putting the scaling infrastructure and materials in place.

To staff this team, we selected some of $[1]$ the best designers and architects at MegaFund. Because the Product Backlog $[1/2]$ required standards and infrastructure development, we also staffed the team with writers and infrastructure and build engineers. As a result, $[2]$ the team was somewhat oversized at 10 people.

At the end of the first Sprint, the team demonstrated $[3]$ a single account management transaction: the team showed existing balances to the client, working from a Web browser, through transaction-specific business objects, to information-specific data objects, through the legacy databases, and back. The team then demonstrated $[3]$ the transaction after restarting the server, as would happen in the event of a crash (plan de continuité d’activité). Several team members $[3]$ showed scalability figures extrapolating the performance of this single transaction across multiple transactions on clusters of the selected server technology. In sum, the team demonstrated that its approach was viable by using it to successfully execute a business transaction.

Expansion et coordination des équipes Scrum
The Product Owner and other stakeholders were so delighted that they wanted to immediately create more teams and set them loose on this project. However, the initial team
$[4]$ required two more Sprints to complete the scaling infrastructure, so it wasn’t until the fourth Sprint that more teams were created. There were now seven teams sprinting, each of which was $[5]$ seeded with someone from the initial team who was charged with providing expertise and guidance to the rest of the team. Each team conducted Daily Scrums, which were followed by a “Daily Scrum of Scrums” at which the members of the initial team met as representatives of their new teams $[6]$ to synchronize the work of these seven new teams. The Daily Scrum of Scrums followed the same format as a regular Daily Scrum.

Lessons Learned

This MegaFund project delivered valuable business functionality from the very first Sprint. Even though three Sprints were required before we could scale the project to seven teams, $[9]$ the stakeholders in the project saw progress being made on their problem from the start. They had to hold themselves back from $[7]$ scaling too quickly, but they were $[9]$ never left feeling that important progress wasn’t being made. The Teams delivered $[7]$ business value to the Product Owners at every Sprint review, and the Product Owners were beside themselves with delight. Sometimes it is difficult for teams to break down complex technical or business problems into something that can be demonstrated within a Sprint, but I’ve yet to see a team fail this challenge.
It is worth underscoring several Scrum practices used in this example that are critical to the success of any scaling effort :

• $[8]$ First, build the infrastructure for scaling prior to scaling.

• Second, $[8]$ always deliver business value while building the infrastructure.

• Third, $[8]$ optimize the capabilities of the initial team, and then staff the additional teams with at least one member of the initial team. These practices are described in more detail in the next section.