Scrum Methodology

Scrum is an agile framework widely used in software development and project management. Scrum is based on iterative cycles and collaboration among team members, promoting adaptability and continuous delivery of value. The key components of Scrum are described below:

• Roles: In Scrum, there are three main roles: the Product Owner, the Scrum Master, and the Development Team.
  • Product Owner: represents the interests of the customer or end-users and is responsible for defining and prioritizing the features of the product in the "product backlog." The Product Owner collaborates with the development team and ensures that the desired value is delivered to the customer.
  • Scrum Master: is a facilitator who helps the team follow the Scrum framework and removes any obstacles that may arise during the process. The Scrum Master also collaborates with the Product Owner and the development team to ensure communication and continuous improvement.
  • Development Team: is responsible for delivering high-quality software increments at the end of each sprint. Development teams in Scrum are usually small (5-9 people) and self-organized, meaning they decide how to work together and how to approach sprint tasks.
• Events: Scrum defines several events to structure the process and promote communication and continuous improvement.
  • Sprint Planning: At the start of each sprint, the team meets to plan the work to be done during the sprint. The team selects product backlog items according to priority and team capacity and creates a "sprint backlog."
  • Daily Scrum Meeting (Daily Stand-up): During the sprint, the team meets briefly every day (usually 15 minutes) to share updates on progress, discuss issues, and adjust the plan if necessary.
  • Sprint Review: At the end of the sprint, the team presents the software increment to stakeholders and gathers feedback and suggestions. This event allows stakeholders to evaluate progress and adjust priorities if necessary.
  • Sprint Retrospective: After the sprint review, the team meets to discuss lessons learned and how to improve in the next sprint. This event promotes continuous improvement and adaptability.
• Artifacts: Scrum uses several artifacts to manage and organize work.
  • Product Backlog: It is the list of pending features, improvements, and bug fixes for the product. The Product Owner is responsible for maintaining and prioritizing the product backlog.
  • Sprint Backlog: It is the set of selected tasks from the product backlog to address during the current sprint. The sprint backlog helps the team plan and organize work during the sprint.
  • Increment: It is the result of the sprint, which should be a potentially shippable product and meet the agreed "definition of done" by the team and the Product Owner.

The Scrum methodology was developed in the 1990s by Jeff Sutherland and Ken Schwaber as an approach to improve software project management and promote the rapid and effective delivery of high-quality products. The idea of Scrum is based on concepts of lean manufacturing, empirical process control theory, and iterative and incremental approaches to software development.

The context for the creation of Scrum lies in the growing dissatisfaction with traditional software development approaches, such as the waterfall model. These approaches often resulted in projects that were delayed, over budget, and did not meet the expectations of end-users. Scrum was designed to address these issues by focusing on collaboration, adaptability, and continuous delivery of value.

Jeff Sutherland, one of the creators of Scrum, is an expert in software development and project management. Prior to developing Scrum, Sutherland worked in various roles in the software industry, including as CTO and VP of product development. Ken Schwaber, the other creator of Scrum, is a software consultant and project management expert who has worked with a variety of organizations to improve their software development processes.

Scrum was first introduced in 1995 at an OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) conference by Sutherland and Schwaber. Since then, Scrum has been widely adopted in the software industry and also in other areas such as project management in general, research, marketing, and more.

A key reference in the Scrum literature is the book "Agile Software Development with Scrum" by Ken Schwaber and Mike Beedle, published in 2001. This book provides a detailed introduction to Scrum and its principles, as well as case studies demonstrating how Scrum can be applied in software development projects.

Other important references include:

• "Scrum: The Art of Doing Twice the Work in Half the Time" by Jeff Sutherland and JJ Sutherland (2014): This book provides an accessible overview of Scrum and its benefits, along with practical advice on how to implement Scrum in different contexts.
• "The Scrum Guide" by Ken Schwaber and Jeff Sutherland (last updated in 2020): This is an online document that provides a detailed description of Scrum, its roles, events, and artifacts. It can be found at .
• "Essential Scrum: A Practical Guide to the Most Popular Agile Process" by Kenneth S. Rubin (2012): This book provides a practical and comprehensive guide to implementing Scrum in software development projects.

Product Owner

The Product Owner (PO) is a key role in a Scrum project, as they represent the voice of the customer and end-users. The main goal of the Product Owner is to maximize the value of the product by guiding the development team in creating features and functionalities that meet the customer's needs. Some specific responsibilities and tasks of the Product Owner include:

• Defining and communicating the product vision: The PO must have a clear understanding of the customer's needs and business objectives, and communicate that vision to the development team and stakeholders.
• Managing the Product Backlog: The PO is responsible for maintaining and updating the Product Backlog, which is a prioritized list of features, improvements, and bug fixes for the product. The PO must ensure that the backlog items are well-defined and prioritized according to the value they bring to the customer.
• Collaborating with the development team: The PO works closely with the development team to answer questions, provide additional details, and clarify requirements as needed. Additionally, the PO helps the team select the right tasks from the Product Backlog during sprint planning.
• Participating in Scrum events: The PO attends and actively participates in events such as sprint planning, sprint review, and sprint retrospective. This allows the PO to provide input and adjust priorities as needed.
• Accepting or rejecting the development team's work: The PO is responsible for evaluating the software increment delivered at the end of each sprint and deciding whether it meets acceptance criteria and the definition of done. The PO may accept or reject the work based on its quality and alignment with customer objectives.
• Communicating with stakeholders: The PO must maintain open and transparent communication with stakeholders, including customers, sponsors, and end-users. This involves providing regular updates on project progress and gathering feedback to improve the product.

The role of the Product Owner is critical in ensuring that the development team works on features and functionalities that bring maximum value to the customer and end-users. A good PO should be communicative, customer-focused, and have prioritization and decision-making skills.

Scrum Master

The Scrum Master is a facilitator and servant leader whose main goal is to ensure that the team follows the Scrum framework and maximizes its efficiency. The Scrum Master is responsible for promoting and supporting Scrum practices, removing obstacles, and fostering continuous improvement. Below are some specific responsibilities and tasks of the Scrum Master:

• Facilitate Scrum events: The Scrum Master organizes and facilitates events such as sprint planning, daily stand-up, sprint review, and sprint retrospective. This includes ensuring that all participants are prepared, that events are conducted effectively, and that time limits are respected.
• Remove obstacles: The Scrum Master works to identify and remove any obstacle or impediment that may affect the progress and efficiency of the development team. This can include resolving conflicts, addressing technical or resource issues, and improving collaboration and communication within the team.
• Protect the development team: The Scrum Master acts as a shield between the development team and external distractions, ensuring that the team can focus on their work during the sprint. This may include managing stakeholder expectations and limiting the amount of unplanned work or changes during the sprint.
• Foster self-organization and collaboration: The Scrum Master supports and guides the development team to be self-organized and collaborate effectively. This includes helping the team make decisions, improve their skills, and share knowledge among team members.
• Improve the process: The Scrum Master promotes continuous improvement by identifying areas for improvement and implementing changes in the process. This may involve facilitating discussions and workshops, collecting data and metrics, and sharing practices and lessons learned.
• Promote adoption and understanding of Scrum: The Scrum Master is a Scrum advocate within the organization and works to increase adoption and understanding of the framework. This may include training other members of the organization, sharing experiences and results, and acting as a resource to address questions or concerns.

The role of the Scrum Master is essential to ensuring the success of a Scrum project by facilitating the process, supporting the team, and promoting continuous improvement. A good Scrum Master should be an effective communicator, problem solver, servant leader, and advocate for the Scrum framework.

Development Team

The development team in Scrum is a multidisciplinary group of professionals responsible for designing, building, and delivering high-quality software increments at the end of each sprint. Team members work collaboratively and self-organize, meaning they make their own decisions about how to work and how to approach sprint tasks. The following are some characteristics and responsibilities of the development team in Scrum:

• Size and composition: Scrum development teams are typically small, with a recommended number of 5 to 9 members. The idea is to keep the team small enough to facilitate communication and collaboration, but large enough to effectively tackle sprint tasks. Development teams are composed of professionals with different skills and specialties, such as programmers, designers, analysts, and testers.
• Self-organization: In Scrum, development teams are expected to self-organize, meaning there is no designated team leader who assigns tasks or makes decisions on behalf of the team. Instead, team members work together to determine how to approach sprint tasks, how to distribute work, and how to resolve issues.
• Collaboration: Collaboration is a key component in Scrum, and development team members are expected to work effectively together. This can include sharing knowledge and skills, reviewing each other's work, and problem-solving together.
• Participation in Scrum events: Development team members actively participate in Scrum events such as sprint planning, Daily Stand-up, sprint review, and sprint retrospective. These events allow the team to coordinate their efforts, monitor progress, and improve their way of working.
• Delivering software increments: At the end of each sprint, the development team must deliver a potentially shippable increment of software that meets the "definition of done" agreed upon by the team and the Product Owner. This involves ensuring that the software is well designed, tested, and documented.
• Continuous improvement: In Scrum, development teams are expected to constantly seek opportunities to improve their way of working and increase efficiency. This can include learning new skills, adopting new tools or techniques, and adjusting the process based on lessons learned.

The development team in Scrum is a collaborative and self-organizing group of professionals who work together to deliver high-quality software increments at the end of each sprint. The effectiveness of the development team is critical to the success of a Scrum project.

Sprint Planning

Sprint Planning is a time-boxed event in Scrum that marks the beginning of each sprint. This event is essential for establishing the sprint goal and determining which Product Backlog items will be worked on during the sprint. The duration of Sprint Planning is typically proportional to the length of the sprint, with a general rule that it lasts approximately 2 hours for every week of the sprint. For example, for a 2-week sprint, Sprint Planning might last around 4 hours.

The main objective of Sprint Planning is for the development team and the Product Owner to collaborate on defining the work that will be addressed in the sprint and how it will be carried out. Sprint Planning can be divided into two parts:

1. Definition of the sprint goal: The Product Owner presents the Product Backlog items that they consider to be of the highest priority, and the development team and the Product Owner work together to define a clear and specific goal for the sprint. This goal provides direction and focus for the team during the sprint and helps ensure that value is delivered to the customer and end-users.
2. Selection and breakdown of Product Backlog items: The development team selects the Product Backlog items that will be addressed during the sprint, taking into account the sprint goal and their capacity for work. The team's capacity is based on the amount of work the team has demonstrated it can complete in previous sprints (velocity) and any factors that may affect their capacity during the current sprint, such as holidays or illness.

Once the Product Backlog items have been selected, the development team breaks them down into smaller and more specific tasks, such as writing code, designing user interfaces, or performing tests. This provides a detailed description of how the work will be carried out and helps the team estimate the effort required to complete each task.

At the end of Sprint Planning, the development team and the Product Owner should have a shared understanding of the sprint goal and the work that will be carried out to achieve it. A tentative plan is also created to complete the sprint tasks, although this plan may change and adapt as the sprint progresses and new information is discovered.

There are several techniques that teams can use to select the backlog items that will be worked on in a sprint. Some of the most common techniques include:

• Value-based prioritization: The Product Owner should prioritize the Product Backlog items based on the value they will provide to the customer and end-users. During sprint planning, the development team selects the highest-priority items to include in the sprint.
• MoSCoW: This prioritization technique uses the categories "Must have," "Should have," "Could have," and "Won't have" to classify the Product Backlog items. The development team and Product Owner work together to decide which items will be included in each category and then select sprint tasks based on their classification.
• Cost of opportunity: This technique involves analyzing the cost of not addressing a Product Backlog item in the current sprint. The development team and Product Owner can estimate which backlog items have the highest cost of opportunity if not addressed and select them accordingly.
• Size and complexity: Sometimes, it is useful to consider the size and complexity of the Product Backlog items when selecting tasks for a sprint. The development team can select items that fit their capacity and skills for the current sprint, which will allow them to complete the work effectively and efficiently.
• Dependencies: It is important to consider the dependencies between the Product Backlog items when selecting tasks for a sprint. The development team and Product Owner must identify and analyze dependencies and select tasks that minimize risks and blockages related to those dependencies.
• Risk reduction: If there are Product Backlog items that present significant risks to the project, the development team and Product Owner may decide to address them early in a sprint to minimize the impact of those risks on the project as a whole.
• Iteration and feedback: In some cases, it may be useful to select Product Backlog items that allow the team to quickly obtain feedback from customers and end-users. This can help validate assumptions, identify problems, and improve the product iteratively.

Ultimately, the backlog task selection technique that the team chooses will depend on the specific needs and objectives of the project, as well as the team's preferences and experiences. It is important for the development team and Product Owner to work together to select backlog tasks in a way that maximizes the value delivered and achieves sprint objectives.

Daily meeting

The Scrum Daily Meeting, also known as the Daily Stand-up or Daily Scrum, is a short and synchronized event that occurs every day during a sprint in the Scrum framework. Its main objective is to provide transparency and synchronization to the development team regarding the progress of work in the sprint and facilitate the early identification of obstacles or impediments.

The Scrum Daily Meeting has the following characteristics:

• Duration: The meeting is brief, usually lasting no more than 15 minutes. This helps keep the meeting focused and efficient.
• Participants: The development team, Scrum Master, and Product Owner are the main participants in the Scrum Daily Meeting. Stakeholders may also attend, but their participation is usually limited and they should not interrupt or divert the purpose of the meeting.
• Time and place: The Scrum Daily Meeting is usually held at the same time and in the same place every day to encourage consistency and routine.
• Structure: During the Scrum Daily Meeting, each member of the development team briefly reports on three points:
  • What they did yesterday to contribute to the sprint goal.
  • What they plan to do today to advance towards the sprint goal.
  • Any obstacles or impediments they have encountered or anticipate that may affect their ability to complete sprint work.
• The Scrum Master facilitates the Scrum Daily Meeting and ensures that the meeting stays within the assigned time and focuses on these three points. If issues or impediments are identified during the meeting, the Scrum Master works to eliminate them or facilitate collaboration between team members to resolve them. However, detailed discussion of these issues should be done outside the Scrum Daily Meeting to not exceed the assigned time.

The Scrum Daily Meeting serves to keep the development team synchronized and focused on the sprint goal. It also provides a mechanism to quickly address issues and obstacles, which helps ensure that the team can maintain an efficient and effective workflow throughout the sprint.

Sprint Review

Sprint Review is a Scrum event that takes place at the end of each sprint and before the Sprint Retrospective. The main purpose of the Sprint Review is to evaluate the finished product increment during the sprint and obtain feedback from the Product Owner, stakeholders, and the development team. This allows for adjustments to the Product Backlog as needed and ensures that the product is being developed according to the expectations and needs of the customer and end-users.

The main characteristics of the Sprint Review are:

• Duration: The Sprint Review is a fixed-time event, and its duration is usually proportional to the duration of the sprint. A general rule is that the Sprint Review lasts approximately one hour per week of the sprint.
• Participants: The development team, the Scrum Master, and the Product Owner participate in the Sprint Review, along with relevant stakeholders such as client representatives, end-users, and members of other teams within the organization.
• Presentation of the product increment: During the Sprint Review, the development team presents the completed product increment during the sprint, demonstrating the new functionalities and features. It is important that the team shows a product increment that meets the "definition of done" and is potentially ready to be delivered to end-users.
• Feedback and discussion: The Sprint Review is an opportunity for the Product Owner, stakeholders, and the development team to discuss the product increment and share their opinions, concerns, and suggestions. The feedback provided during this discussion can be used to adjust the Product Backlog, change the prioritization of tasks, and improve the product in future sprints.
• Product Backlog update: Based on the feedback and discussion during the Sprint Review, the Product Owner can update the Product Backlog as needed, adding, modifying, or removing items according to business needs and stakeholder expectations.
• Planning for the next sprint: The Sprint Review can also be an opportunity to start planning for the next sprint, identifying Product Backlog items that could be addressed based on the feedback received and business priorities.

The Sprint Review provides an opportunity to evaluate the work done during the sprint and obtain valuable feedback from stakeholders. This feedback is critical to ensure that the product is being developed effectively and meets the needs and expectations of the customer and end-users. Additionally, the Sprint Review allows the development team to continuously adapt and improve the product over time.

Sprint Retrospective

The Sprint Retrospective is an event in the Scrum framework that occurs after the Sprint Review and before starting the next sprint. The main purpose of the Sprint Retrospective is to reflect on the just-completed sprint and look for opportunities to improve the process and the way the development team works together. The Sprint Retrospective is crucial for fostering continuous improvement and learning within the team.

The key characteristics of the Sprint Retrospective are:

• Duration: The Sprint Retrospective typically lasts about one and a half hours for every two weeks of the sprint's duration. However, the duration may vary depending on the team's needs and project context.
• Participants: The main participants in the Sprint Retrospective are the development team, the Scrum Master, and the Product Owner. Unlike the Sprint Review, stakeholders generally do not participate in the Sprint Retrospective, as this meeting focuses on the team's internal functioning and processes.
• Structure: The Sprint Retrospective usually follows a structure in which team members discuss three main areas:
  • What went well during the sprint: Team members share their positive experiences and highlight aspects of the process that helped them succeed.
  • What did not go well or could be improved: Team members identify problems, challenges, or areas for improvement in the process or the way they worked together.
  • Improvement actions: The team agrees on specific actions to address the identified areas for improvement and assigns responsibilities for carrying out these actions in the next sprint.
• Facilitation: The Scrum Master generally facilitates the Sprint Retrospective, ensuring that the discussion remains constructive and focused on continuous improvement. It is also the Scrum Master's responsibility to ensure that a safe and trusting environment is established where team members feel comfortable sharing their opinions and concerns.
• Follow-up: It is important to follow up on the agreed-upon improvement actions during the Sprint Retrospective and ensure that they are implemented in the next sprint. This may include reviewing the improvement actions in future Sprint Retrospectives to evaluate their effectiveness and make additional adjustments as necessary.

The Sprint Retrospective fosters continuous improvement, learning, and adaptation within the team. By reflecting on their experiences and looking for opportunities to improve, teams can adjust their approach and work more effectively and efficiently in future sprints.

Product Backlog

The Product Backlog is one of the key artifacts in the Scrum framework and represents an ordered list of all the items that are necessary to complete the product. The Product Backlog evolves over time and is in constant flux as the team learns more about the product and user needs. It is the only source of requirements for any changes that need to be made to the product and is therefore essential for planning and developing the product in Scrum.

Some important characteristics of the Product Backlog include:

• Product Backlog items: Product Backlog items may include features, functionality, improvements, bug fixes, and any other tasks necessary for the successful development of the product. Each Product Backlog item should have an associated value, effort estimation, and preferably a clear and concise description.
• Owner: The Product Owner is responsible for the Product Backlog, including its creation, maintenance, ordering, and updating. The Product Owner works closely with the development team and stakeholders to ensure that the Product Backlog reflects the needs and priorities of the business and end-users.
• Prioritization: The Product Backlog is ordered by priority, which means that the most important and valuable items for the product are at the top of the Product Backlog, while lower priority items are at the bottom. The Product Owner is responsible for prioritizing the Product Backlog based on business value, user needs, and other relevant factors.
• Refinement: The Product Backlog is constantly refined as the development team and Product Owner learn more about the product and user needs. This may include adding, modifying, or deleting items from the Product Backlog, as well as adjusting prioritization and effort estimates. Product Backlog refinement is an ongoing and collaborative process that involves both the development team and the Product Owner.
• Estimation: Product Backlog items typically have an associated effort estimate, which represents the amount of work the development team believes is needed to complete the item. Estimates may be expressed in terms of time, story points, or any other unit the team deems appropriate. Estimates help inform sprint planning and the development team's capacity.
• Transparency: The Product Backlog should be a transparent and accessible artifact for all team members and stakeholders. This ensures that all stakeholders have a clear understanding of the product priorities and requirements and can contribute to the planning and development process.

The Product Backlog provides a unique and shared vision of product priorities and requirements. By maintaining and refining the Product Backlog, the development team and Product Owner can ensure that the product is developed efficiently and effectively to meet the needs and expectations of end-users and stakeholders.

Sprint Backlog

The Sprint Backlog is another important artifact in the Scrum framework. It is a list of selected items from the Product Backlog that the development team commits to completing during a specific sprint. The Sprint Backlog is an essential tool for the development team as it provides a clear view of the tasks that need to be accomplished during the sprint and helps ensure that the team is focused on working towards the sprint goal.

Some key characteristics of the Sprint Backlog include:

• Item selection: During Sprint Planning, the development team selects the items from the Product Backlog that will be included in the Sprint Backlog. The selection is based on the prioritization of the Product Backlog and the team's capacity to complete the work during the sprint.
• Team commitment: The development team commits to completing the selected items from the Sprint Backlog during the sprint. This commitment is essential to ensure that the team is focused on delivering a potentially shippable product increment at the end of the sprint.
• Task breakdown: The items in the Sprint Backlog are often broken down into smaller, manageable tasks that can be assigned to individual team members. This breakdown helps ensure that the work is effectively distributed and that each team member has a clear understanding of their responsibilities during the sprint.
• Flexibility: Although the development team commits to completing the items in the Sprint Backlog, this artifact is not set in stone. Throughout the sprint, the team may discover that adjustments to the Sprint Backlog are necessary to adapt to new circumstances or address unforeseen issues. In this case, the team can work with the Product Owner to make appropriate adjustments to the Sprint Backlog.
• Updating and tracking: During the sprint, the development team regularly updates the status of the Sprint Backlog and individual tasks. This allows the entire team to track the progress of the sprint and ensure that the appropriate items from the Product Backlog are being addressed. Sprint Backlog updates are also discussed during the Daily Scrum Meeting, where team members report on their progress and address any obstacles or impediments.
• Ownership: Although the Sprint Backlog is an artifact created during Sprint Planning, it is the development team's responsibility to maintain and update the Sprint Backlog throughout the sprint. The Scrum Master and Product Owner may also support the team in managing the Sprint Backlog, but the primary responsibility rests with the development team.

The Sprint Backlog is a key component of the Scrum process, as it provides a clear and shared view of the tasks that the development team must complete during a specific sprint. By maintaining and updating the Sprint Backlog, the development team can ensure that they are working efficiently and focused on achieving the sprint goal and delivering a valuable product increment at the end of the sprint.

Increment

The Increment is an essential artifact in the Scrum framework that represents the tangible and functional outcome delivered at the end of each sprint. It is an updated version of the product that includes all completed elements from the Product Backlog during the sprint, as well as all previous increments. The Increment must be "potentially shippable," which means it meets the quality standards and Definition of Done agreed upon by the team and could, in theory, be delivered to the end user or stakeholder.

Key characteristics of the Increment include:

• Work integration: The Increment is a combination of all completed elements from the Product Backlog during the sprint, as well as any previously completed work in previous increments. This means that the Increment represents the current state of the product at any given time.
• Potentially shippable: For an Increment to be considered "potentially shippable," it must meet the Definition of Done agreed upon by the team and meet the necessary quality standards. This does not necessarily mean that the Increment is delivered to the end user or stakeholder after each sprint, but it should be in a condition where it could be delivered if deemed appropriate.
• Evaluation and validation: The Increment is presented and evaluated during the Sprint Review, where the development team, Product Owner, and stakeholders review the work completed during the sprint and discuss next steps. The Sprint Review is an opportunity to receive feedback and validate that the Increment meets the expectations and needs of the business and end users.
• Adaptation: As new increments are created and delivered, the team can use the information and feedback gathered to adapt and improve the product and development process. This is in line with the agile approach of Scrum, which is based on adaptation and continuous improvement.
• Ownership: The development team is responsible for creating the Increment during each sprint. This includes ensuring that all selected elements from the Product Backlog for the sprint are completed according to the Definition of Done and effectively integrated into the product.

The Increment is a critical component of the Scrum process, as it represents the real value delivered to the business and end users throughout the project. By creating potentially shippable increments at the end of each sprint, the development team can ensure they are working efficiently and focused on delivering a high-quality product that meets the expectations and needs of the business and end users.

Control charts are visual tools that help monitor the progress and performance of the team during a sprint. Some of the most commonly used control charts in Scrum include:

Burn-down Chart

The burn-down chart is one of the most common control charts in Scrum. It shows the amount of remaining work (in story points, hours, or any unit of measurement) compared to the available time during a sprint. The chart helps identify whether the team is on track to complete the work within the sprint deadline and shows how the amount of remaining work evolves over time. This type of chart can also be created at the product level, so that the amount of pending work to complete the product is visualized over weeks, months, or sprints.

Burn-up Chart

The burn-up chart is similar to the burn-down chart but shows the amount of completed work instead of the amount of remaining work. This can provide a different perspective on the team's progress and value delivery. The burn-up chart can also include a scope line, which represents the total amount of work in the sprint, helping identify changes in project scope.

Velocity Chart

The velocity chart shows the amount of work completed by the team (usually in story points) during each sprint. This chart helps evaluate the team's capacity and can be useful for predicting future performance and planning future sprints. The team's velocity may vary from one sprint to another, but over time, an average velocity can be established.

Cumulative Flow Diagram (CFD)

Although the CFD is more common in Kanban, it can also be used in Scrum to monitor the accumulation of work in each stage of the workflow over time. This chart can help identify bottlenecks and imbalances in the process.

Cycle Time Chart

Like in Kanban, this chart shows the time it takes to complete a task from start to finish. In the context of Scrum, the cycle time chart can provide information about process efficiency within a sprint and help identify areas for improvement.

Cycle Time Distribution Chart

This chart shows the distribution of cycle time for all completed tasks in a given period, such as a sprint. This chart can help identify variability and anomalies in cycle time.

By using these control charts in Scrum, you can monitor process performance, identify areas for improvement, and make informed decisions to optimize efficiency and value delivery during a sprint.