The Scrum Framework is the preeminent Agile Development method in software development and non-technical areas where the term 'Scrum' has its roots. The 2020 Scrum Guide accommodates numerous updates and changes that make it the best guide yet. If you haven't done so already, we have discussed everything regarding the scrum guide as per the updated Scrum Guide 2020. This latest replay is cleaner, clearer, and more comprehensive. Moreover, the updated changes in the 2020 Scrum Guide are expected to drive the culture, focus, and alignment needed to innovate, create, and succeed.
What is a Scrum Guide?
The Scrum Guide is a formal rule book to execute the Scrum values and fundamentals and has undergone several iterations since its first publication in 2010. Ken and Jeff announced their learnings and ideas regarding the iterative software development lifecycle at the OOPSLA Conference in 1995. However, to subsequently represent these ideas were to the public years later in consolidated formal documentation known as Scrum Guide.
Now, we shall discuss the purpose of the scrum guide.
Purpose of the Scrum Guide?
The Scrum Guide describes scrum, its core values, and fundamentals. Each concept defines in the guide symbolizes an indispensable part of the scrum that serves a specific purpose. Here, the aim is to deliver value and improve outcomes incrementally. Thus, customizing the core values, or eliminating the Scrum rules, limits the overall Scrum profits with useless outcomes at the end of the project deadline.
Scrum is being adopted in many domains holding complex work, apart from software product development, where scrum has its foundation. As scrum adopt spreads, developers, researchers, analysts, scientists, and other professionals do the work. Thus, this guide can find only the basic rules and processes related to scrum. However, they are context-sensitive and can regulate according to shifting organizational prerequisites.
Lastly, scrum is free to use. Therefore, the overall esteem of the Scrum framework written in the guide is unchangeable. The guide aims to set forth the framework lucidly and reduce the unnecessary portions, making it understandable to a larger audience.
Let us first understand what the scum is,
What is Scrum?
Scrum is a framework for developing and lasting complex products. Also, it is the lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.
Scrum is simple. Scrum gives you the energy to merge various techniques and methodologies to develop and deliver valuable products. The Scrum framework is intentionally incomplete, only describing the parts required to apply Scrum theory. In addition, Scrum is built upon the collective intelligence of the professionals using it. Rather than provide people with accurate instructions, the rules of scrum guide their relationships and interactions.
A Scrum Master (also known as Agile Coach), similar to the comparison of a team facilitator, is essential to motivate and cultivate the Scrum environment where:
-
Product Owner orders a complicated problem into a Product Backlog.
-
The Scrum Team involves selecting the work to increment value during a Sprint.
-
The Scrum Team and its stakeholders audit the results and adjust for the next Sprint.
-
Repeat the process.
Now, let us study the scrum theory
Scrum Theory
Scrum is established on empiricism and lean thinking.
Empiricism defines working based on facts, experience, and evidence. For instance, to create a small transferable product in short cycles, review what and how you have created it. In addition, adapt the product and the way you build it, with built-in mechanisms for transparency to enable clear inspection.
Lean thinking minimizes waste and focuses on the essentials. The waste reduction helps reduce the costs and time spent on it. Lean management helps easily focus on the tasks to improve efficiency by reducing waste like defects, overproduction, unused resources or talents, transportation, excess processing, waiting, motion and inventory.
Scrum is based on an incremental and iterative approach that helps optimize predictability and reduce risks. Skilled persons are grouped in the scrum, and hence collective and sharing work helps improve the quality and efficiency of the work.
Scrum associates four formal events for inspection and adaptation within an accommodative event, the Sprint. These events work because they apply the empirical Scrum support of three pillars of the scrum framework: transparency, inspection, and adaptation.
Transparency
The emergent procedure and work must be evident to those who perform and receive the work. Important decisions are taken based on the three formal artifacts. Artifacts having low transparency can lead to decisions that diminish the value and increase risk. Transparency enables inspection so that proper leading of the tasks can be done.
Inspection
Frequent inspections of the Scrum artifacts and the progress toward the goal are necessary to find problems. Any variances or deviations from the plan should be identified at the initial stages. For inspection, cadence is provided in the form of five events. An inspection enables the adaption as inspection without adaption is pointless. Scrum events are designed for inducing changes.
Adaptation
Any process aspects deviate outside acceptable limits, or the resulting product is unacceptable; it must adjust the applied process or the materials being produced. Also, it must make as soon as possible to minimize further deviation. If people involved in adaption cannot self-manage, it will become difficult. The scrum teams should adapt to the changes learned from the inspection.
Now, we have got an idea of scrum and its theories.
What is a Scrum Framework?
According to Scrum.org, Scrum is a framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value.
Scrum is:
-
Lightweight
-
Easy to follow
-
Tough to master
Scrum was used in the early 1990s to handle complex problems. It is not a conclusive procedure, methodology, or operation. It is instead a structure within which different processes and techniques can be utilized. Scrum makes the relative effectiveness of the product management and working techniques transparent so that you can consistently improve the product, the team, and the working environment.
The Scrum Framework consists of Scrum Teams, their positions, activities, objects, and rules. Every person in the Scrum team serves a particular purpose and is central to the effectiveness and use of Scrum.
Scrum's laws tie activities and relics positions together, regulating interactions and contact with them. The Scrum rules are listed in the whole of this document.
SCRUM employs an analytical approach (or also refers to as empiricism) to respond to the client's changing needs. Empiricism is the process whereby decisions are taken, depending on what is already observed. The empirical approach involves operating in a fact-driven, experiential, and evidence-based way. In particular, change is focused on analyzing facts, not fictional plans driven on vast quantities of external criteria.
In short, we should learn from previous errors and interactions and strengthen them.
Scrum's three pillars which uphold all execution of empirical process control are:
-
Transparency
-
Inspection
-
Adaptation
This article explains the three pillars of Scrum Framework.
The Three Pillars of Scrum Framework
Transparency
By transparency, we mean everybody in the agile team must have a good view of the Scrum objectives and their positions and duties as individuals. How do you know you have a high degree of openness inside your team?
Firstly, an agile team should have a shared language. Everyone should know what their goal is and what needs to be achieved to accomplish that goal, from the Scrum Master to the Product Creator, members of the team and shareholders.
The team needs to agree with a common concept of what was done.
Because when an inventory backlog increment or job is completed, everyone knows what it entails, and it suggests.
There is a knowledge exchange that is simple and straightforward.
Everyone can grasp the Scrum Artifacts fully. This includes product backlog, sprint review, project goal and goal, rise, etc.
They must also be available at regular sessions such as Daily Scrum, sprint review, etc., and must be mindful of the resources used by the entire team (e.g., Burndown Map, Scrum board).
Inspection
Scrum objects need to be tested regularly and advance against a target for identifying unwanted variances. Scrum analysis should be performed using scrum tasks such as:
-
Usage of a standard Scrum board as well as other facts to make plain to all the project's current status
-
Collecting consumer and other stakeholder input during the Build Epic(s)
-
Build inventory backlog prioritized and carry out release preparation processes
-
Service proprietor review and authorization of the deliverables
-
The Show and Confirm Sprint consumer
Adaptation
When an auditor decides that one or more parts of a procedure are deviating beyond reasonable boundaries, and the resultant product is inappropriate, the system or the manufactured content must be changed. To mitigate any variance, the improvement must be made immediately.
Scrum recommends four systematic inspection and adaptation activities, as outlined in this document's Scrum Events section:
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective
Scrum Guide 2021: Scrum Master: From 'Servant Leader' To 'A Leader Who Serves'
Earlier, Scrum Guides was introduced to two teams: the development team, which means those who have done the work, and the Scrum Team, which incorporates the development team, the Scrum Master, and the Product Owner. This concept of a separate team has sometimes guided to an "us and them" interconnection between the Development Team and Product Owner. There is just one team, the Scrum Team, focused on the same objective, with different liabilities for the Product Owner, Scrum Master, and Developers.
The Scrum Team comprises one Scrum Master, one Product Owner, and Developers. In a Scrum Team, there are no sub-teams or hierarchies. Scrum Teams are cross-functional, which means the members have all the skills necessary to create value for each Sprint. However, the Scrum Team is small enough to remain agile and large enough to complete significant work.
The Scrum Team is liable for all product-related actions from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and things that might require. The whole Scrum Team is responsible for creating a valuable, useful increment for every Sprint. In addition, the scrum guide describes three specific accountabilities within the Scrum Team: the Developers, the Product Owner, and the Scrum Master.
Developers
Developers are the Scrum Team committed to creating any aspect of a usable Increment for each Sprint. However, the Developers are always answerable for:
-
Building a plan for the Sprint, the Sprint Backlog
-
Instilling quality by holding to a Definition of Done
-
Accommodate their plan each day toward the Sprint Goal
-
Holding each other liability as professionals
Product Owner
The Product Owner is accountable for exaggerating the product's value. The Product Owner is also accountable for adequate Product Backlog management, which includes:
-
Developing and explicitly communicating the Product Goal
-
Creating and broadcasting Product Backlog elements,
-
Legislate Product Backlog elements
-
Assuring that the Product Backlog is transparent, visible, and understood
Scrum Master
The Scrum Master is accountable for establishing scrum. They do this by helping everyone understand Scrum theory and practice to boost its proceeding within the Scrum framework for Scrum Teams and organizations. Scrum Masters are true leaders who will serve the Scrum Team and the organization.
The following are several ways the Scrum Master will help the Scrum Team:
-
Train team members to work on self-management and cross-functional abilities.
-
Causing the removal of the aroused impediments to the Scrum Team's progress.
-
Assuring that all Scrum events take place and are positive, productive, and kept within the timebox.
-
Enabling the Scrum Team to focus on creating high-value Increments that meet the Definition of Done.
The following are many ways the Scrum Master benefits the organization.
-
Leading, training, and coaching the organization and the team members in its Scrum fostering
-
Planning and advising Scrum application within the organization
-
Guiding employees and stakeholders to understand and enact an empirical approach to complex work
-
Removing barriers between stakeholders and Scrum Teams
The following are many ways the Scrum Master assists the Product Owner.
-
Guiding find techniques for adequate product goal definition and Product Backlog management
-
Enabling the Scrum Team to understand the requirement for clear and crisp Product Backlog items
-
Helping construct empirical product planning for a complex environment
-
Facilitating stakeholder collaboration as requested or needed
Now, we move to understand what is scrum event
Scrum Events
A Sprint is a container for other events. Each event in scrum is an official opportunity to audit and adapt Scrum artifacts. The purpose of the events is to enable the transparency of the tasks. Any failure in event operation will create new problems for inspection and adaptation.
The Sprint
Sprints are the most important in the scrum for turning ideas into values.
These events in the scrum are of fixed length and will be created based on consistency. Once the current sprint is over, the new sprint will be followed. For achieving the product goal, the various involved processes are sprint planning, sprint review, daily scrum, and sprint retrospective.
Sprint is based on the following:
-
Accepting changes that will affect the sprint goal is not a smart option
-
The quality should not be compromised at any cost
-
The product backlog can be feasible as per the requirements
-
The scope may be clarified and negotiated again with the product owner
Sprint Planning
The work to be performed in the sprint is initiated and created here. This sprint planning involves the entire Scrum team. The most important product backlog items are discussed along with the product goal. In addition, people can be invited from outside of the team to provide any advice.
Three Sprint Planning Topics
The 2017 Scrum Guide concentrated on the 'What' and 'How.' Now, we have three equally prime points to cover:- "Why," "What," and "How."
Following are the three crucial questions about Sprint Planning from the Scrum Guide, 2020:
1. Why is this Sprint valuable?
Product Owner introduces how this Sprint could maximize the product's esteem. Then, the whole Scrum Team describes the Sprint Goal before finishing the Sprint planning.
2. What is the purpose of this Sprint?
Through a conversation with the Product Owner, the developers select items from the Product Backlog to include in the current Sprint.
3. How will the chosen work get done?
The Developers decide how they will apply the Product Backlog items and divide them into smaller lists or tasks.
Daily Scrum
Daily Scrum is a meeting occurring for 10 to 15 minutes. Developers and Scrum Master will be attending the meeting to discuss some of the questions. It will occur daily at the same time and place. In addition, the progress towards the sprint goal is inspected, adapting the sprint backlog, and planning the future works are performed in daily scrum.
The main purpose of this scrum meeting is to follow the progress and improve collaboration and communication.
Next, we shall study the questions to answer in scrum meetings.
Answering Three Questions at Daily Scrum Meetings
The three elective questions "What did I do yesterday?", "What will I do today?" and Are there any impediments? These are removed from the daily scrum. Therefore, the Daily Scrum aims to review the progression of the Sprint Goal and accommodate the Sprint Backlog as essential, adjusting the upcoming planned work.
Sometimes the Daily Scrum recognizes conversations that need to take place beyond the event's 15-minute timebox. Moreover, the introductory guide stated that these conversations, often called a 'parking lot,' occur right after the Daily Scrum. The 2020 Scrum Guide approves the Scrum Team when these important conversations occur.
This change doesn't mean you can no longer use the above three questions. Instead, this change gives the Scrum Team more flexibility to design their Daily Scrum as long as it enlists towards the progress of the Sprint goal.
Sprint Review
This sprint review needs to understand and inspect the sprint outcome and find the adaptions in the future. The result of the current work and the progress toward the product goal review is here in the sprint review. In addition, any changes that are identified in the sprint will be identified and reviewed.
With new changes and available opportunities, the product backlog adjusts to meet those changes. The time for a sprint review is four hours maximum for a one-month Sprint.
Sprint Retrospective
To increase the quality and effectiveness of the product, a sprint retrospective will be helpful. The scrum team is inspected in a sprint retrospective to understand how the last sprint went. What went well and what did not are studied in this retrospective to solve them effectively.
The helpful changes that could improve the effectiveness of the product are inspected. In addition, the sprint is over after the sprint retrospective. For every one-month sprint, the sprint retrospective will be a maximum of three hours.
Next, we will discuss in detail the Scrum artifacts.
What are Scrum Artifacts?
A scrum artifact is a collection of information used by a scrum team to define the product or service being developed, the stages necessary to generate it, and the actions required during its development. Scrum artifact provides information on the performance of a sprint. Scrum artifacts are essential for scrum teams because they enable core scrum qualities such as transparency, inspection, and adaptability. This is important, especially for remote teams who may work from home because it gives a platform for them to monitor how they're performing on a certain sprint. This keeps everyone, no matter where they are, on the same page.
Scrum relies on small teams of cross-functional people who may self-organize to complete tasks. The scrum team should have a shared understanding of the task to be done for this to happen. Scrum artifacts come into play here. Scrum artifacts keep everyone on the team on track as they work toward the sprint goal. Even when large or last-minute changes occur, Scrum artifacts continue to capture the important information the team requires at various checkpoints to achieve the final results. Now, talking about ways which scrum artifacts are helpful.
Scrum Artifact Help in the Following:
-
Making a list of your product management goals and objectives
-
Making a list of tasks that can help you achieve these goals
-
Tasks can be organized into sprints based on their relevance and interdependence
-
Helps in completing the tasks on schedule
-
Examine and evaluate the data to see how well they correspond with the goals
So these were some of the reasons why scrum artifacts are helpful and why they are widely popular among many organizations.
The 7 Scrum Artifacts
The seven scrum artifacts that play a major role in improving the performance of a scrum team are product vision, product backlog, sprint vision, sprint backlog, the definition of done(DoD), product increment, and burndown chart. Now, let us discuss the scrum artifacts one by one in detail:
Product Vision
A product vision, also known as a product vision statement, outlines your product's broad, long-term objective. Vision statements are aspirational and express clearly where the product intends to go and what it hopes to achieve in the long run.
The statement should act as a guide and reminder to all stakeholders engaged in the creation of a product, which includes the product team, development, executive staff, marketing, and others, to understand the common shared goal they're attempting to achieve with this product. Your vision statement should also address why you are developing the product and what the organization expects to achieve with it in the future.
Creating a vision helps your team to design your product from the top down. To explain this in simple terms, you start with a high-level vision statement and then transform the vision into a strategic guide and action plan, which is known as the product roadmap. The strategic perspective of the roadmap is then translated into a tactical development strategy.
Some of the Benefits of Product Vision:
-
A product vision statement may offer value by making it easier for your team to express the high-level aim driving the development of your product.
-
They help in the coordination of the many groups and departments within the organization that is working on the project.
-
With product vision, there is a common vision, so everyone has something to refer to, which may assist remind them of why they're doing what they're doing.
Drafting a vision statement should be the team's first step in moving to the next phase of any new product, and it should always come before working on the product plan. So this was about the product vision. Now let us move on to our next Scrum Artifacts - Product Backlog.
Product Backlog
The Product Backlog is an ordered list of features that must be included in the final product, and it acts as the single source of requirements for any modifications to the product.
The Product Backlog describes all of the features, functions, requirements, additions, and fixes that will be added to the product in future editions. Product Backlog items include the following attributes: a description, an order, an estimate, and a value. These are commonly referred to as User Stories. The Product Owner is in charge of the Product Backlog's content, availability, and ordering.
A Product Backlog is a continuing process. The oldest version of it may include the criteria that were initially identified and best understood. As the product and the environment in which it will be utilized develop, so does the Product Backlog. The Product Backlog is always evolving to include what is needed to make it effective. As long as a product exists, so does its Product Backlog.
Importance of Product Backlog
The Product Backlog grows larger and more comprehensive as the product being created is used and earns value. Changes in company requirements, market conditions, or technology affect the Product Backlog, making it a living artifact. Refining the Product Backlog involves adding descriptions, estimates, and priority orders to the Product Backlog items. This is a continuous process carried out by the Product Owner and the Team. The Scrum Team determines how and when to refine the product backlog.
Product Backlog items can be modified by the Product Owner at any time or at their discretion. Higher-ordered Product Backlog items are typically more clear and thorough than lower-ordered things. More exact estimations are created as a result of improved clarity and detail. The less detail there is, the lower the order. Product Backlog items that are likely to be candidate needs for the next Sprint are refined so that they may be created during the Sprint. Product Backlog items that the team can build in one Sprint are declared ready for selection in a Sprint planning meeting. So, this was about the Product Backlog. Now, let us move on to the next scrum artifact - Sprint Vision.
Sprint Vision
A sprint Vision is a brief description of what the team intends to accomplish during an Agile sprint. It is a measurable objective defined by the team and the Product Owner that is time-bound for the length of the Sprint.
Despite the fact that the sprint vision or sprint goal is not always specified as an artifact, it is a crucial aspect of the scrum framework. When designing a sprint, the scrum team develops a sprint vision. It informs the scrum team on why they are investing their time, money, and effort in the Sprint.
A sprint goal specifies the Sprint's goal and guides future decision-making as the project progresses. If new issues or tasks arise throughout the Sprint, the sprint vision provides a reference for the team on what to focus on and how to arrange or reprioritize various tasks.
Some of the Benefits of Sprint Vision Are:
-
In daily scrums, sprint vision provides clarity and purpose
-
Set a standard for measuring progress, value, and results
-
Allow for some flexibility in the functionality implemented throughout the Sprint
-
Assist the Product Owner in creating the product roadmap
-
Help with sprint planning
-
Allow for more efficient and coordinated decision-making
So, this was about Sprint Vision. Now, let us move on to the next scrum artifact - Sprint Backlog.
Sprint Backlog
The Sprint Backlog consists of the Product Backlog items chosen for the Sprint, as well as a plan for delivering product increment and achieving the Sprint Goal. It is the team's forecast of what functionality will be available in the next increment and the work mandatory to deliver that functionality as a working product Increment.
The Sprint Backlog is a plan with sufficient depth for the team to track in the Daily Scrum. Throughout the Sprint, the team adjusts the Sprint Backlog, and the Sprint Backlog develops. As the team goes through the plan and learns more about the work required to achieve the Sprint Goal, this emergence happens.
As some new work is required, the team adds it to the Sprint Backlog. The estimated remaining work is updated as work is performed or completed. Elements of the plan that are deemed unneeded are removed. During a Sprint, only the team has the ability to update its Sprint Backlog. The Sprint Backlog is a highly visible, real-time representation of the work that the team intends to do during the Sprint, and it is owned entirely by the team.
However, the development team is not entirely permitted to change the items in a sprint backlog. Before making any modifications to the sprint backlog, the team must first negotiate with the product owner, product manager, or scrum master. This communication between the development team and the scrum master is beneficial. The reason for this is that rather than completely eliminating a process, it allows you to find methods that help to create smaller parts of the process so that they can be completed relatively easier. Sprint backlogs are created by taking a task from the product backlog and breaking it down into smaller, actionable sprint tasks.
Example
Assume you wish to integrate a web page website. Adding a web page requires a number of steps, including the creation of a suitable design. The product backlog is a list of generic tasks such as creating a webpage. The sprint backlog comprises specific and smaller activities that are driven by a larger task. For example, creating the User Interface Design for that web page is a task that should be added to the sprint backlog. This was about Sprint Backlog. Now, let us move on to the next Scrum Artifacts - Definition of done(DoD).
Definition of Done (DOD)
The Definition of Done (DOD) specifies that all elements of a user story in a sprint backlog have been completed. Now, for those of you who do not know what a user story is. A user story is an informal explanation of a software system's features and characteristics. It is basically the user or client's requirements of what they want to do with the software product.
Now, The scrum team must agree on what "done" includes. They should define "done" and utilize it as a checklist while they work on their user stories. So, the team can sit together and decide what tasks need to be finished by the end of the Sprint and set each of those tasks as "done." So, as they complete each of the tasks in the checklist, they can mark those as done.
During the first sprint planning, the scrum team can develop its definition of done (DoD). It may then be improved upon during sprint retrospectives, which means that the DoD is fixed. It might be modified accordingly throughout the process. And with agile, there are a lot of "dones." Each feature is dependent on the completion of another feature before the product is really finished and released. That would be the end result. However, each Sprint contains a characteristic that must be completed by the end of the Sprint. By done, it implies that if that feature had to be released on its own, it could be released.
An Example of Definition of Done
Let's assume, for a development team, the program is covered by automation testing that conforms to a given specification and is sent to a production environment. When assessing available scrum tasks, a team that lacks a defined definition of done will frequently find themselves in sprint review wondering, "Is this done?"
The concept of done helps in the determination of an increment. The increments should be provided in completely usable packages that are appended to the last increments. Done signifies that a task has been done and maybe shut for burndown tracking. The project should ideally be complete after each iteration. This is not always the case, however. Things arise that must be dealt with, leading the project to pivot quickly to accommodate these changes. Therefore, it is not advisable to release after every Sprint. To track the project's progress, however, each feature must be completed within the Sprint. Therefore, completion involves ensuring that each feature has been fully developed, tested, and approved by the product owner. It is then and only then complete. This was about the definition of done. Now, let us move on to our next scrum artifact, which is product increment.
Product Increment
This is the most important scrum artifact. The product increment is the sum of all the product backlog items accomplished during a sprint. Because each Sprint has the ability to produce product increments, the product increment must meet the team's definition of done and be acceptable to the product owner. The increment is the sum of all Product Backlog items done during a Sprint and all previous Sprint increments. The new increment must be a functioning product at the completion of a Sprint, which implies it must be functional.
Importance of Product Increment
The Scrum Team must reach an agreement on what constitutes an Increment. The Scrum Team will determine how this varies, but team members must share an understanding of the work to be done. This is used to determine when work on the product Increment is complete.
The same idea helps the team in determining how many Product Backlog items it may choose during a Sprint Planning session. Each Sprint's goal is to provide Increments of potentially releasable functionality. Every Sprint, teams release an increment of product features. Because this increment is usable, a Product Owner may opt to release it right away. If the understanding of an increment is part of the development organization's conventions, rules, or guidelines, all Scrum Teams must adhere to it at a minimum. If it is not a development organization tradition, the Scrum Team must design an Increment definition that is appropriate for the product.
Each increment is additive to all previous Increments and properly tested to ensure that they all operate together. Increment definitions should expand to include more reliability requirements as Scrum Teams grow. Any single product should have a definition of increment that serves as a guideline for all work done on it. This was about Product Increment. Now, let us move on to our next topic and talk about the Sprint Burndown Chart.
Burndown Chart
Burndown Chart is a graphical representation of how quickly the team completes the user stories or items on the product backlog. As a result, a burndown chart shows the total effort versus the amount of work for a sprint.
The burndown chart is a critical artifact to not overlook, despite the fact that it is not typically regarded as one of the fundamental scrum artifacts. A burndown chart's objective is to ensure that the project is on track and that the deliverable will meet expectations and arrive on time.
The velocity of a scrum team is defined as the number of narrative points in the user story that have been completed throughout the Sprint. Partially completed tasks are not considered towards velocity. The total amount of work pending in the Sprint Backlog may be totaled at any point throughout the Sprint. The team keeps track of the overall work remaining for each Daily Scrum to forecast the possibility of meeting the Sprint Goal. The team may manage its progress by tracking the remaining work during the Sprint.
Sprint Burn-Down Chart
It is a technique for tracking the work done by the Scrum Team. This method of tracking Sprint's progress toward the Sprint Goal has shown to be successful. At least once every Sprint Review, the Product Owner keeps track of the amount of work remaining. The Product Owner compares this amount to the amount of work left at prior Sprint Reviews to measure progress toward finishing the estimated work by the deadline.
During sprint planning, teams can refer to the previous burndown charts to determine how many tasks they can realistically achieve in the following Sprint. Teams can use in-progress burndown charts to determine whether they are on track to complete the Sprint successfully. During the sprint review, teams may refer back to the burndown chart to determine where they exceeded or fell short of expectations. Over time burndown charts assist teams in better improving their estimations during the scrum planning stages. This was about the Sprint Burndown chart. Now, I guess you have some idea about Sprint artifacts. So, let us now move on to our next section of the blog and discuss some of the benefits of scrum artifacts.
Conclusion
The Scrum Guide has evolved considerably since its earliest days, and the 2020 version reflects some of its most meaningful changes yet, from the shift to a single, unified Scrum Team to the introduction of commitments tied to each artifact: the Product Goal for the Product Backlog, the Sprint Goal for the Sprint Backlog, and the Definition of Done for the Increment. These changes bring sharper focus and transparency to how Scrum Teams plan, execute, and inspect their work throughout every Sprint.
Understanding the Scrum Guide in depth, its events, artifacts, accountabilities, and the three pillars of transparency, inspection, and adaptation, is essential for anyone looking to apply Scrum effectively rather than just following it by rote. But reading the guide is only the first step. Turning that knowledge into practical skill takes structured training and real-world application.
If you are ready to build a career around Scrum or strengthen how your team applies it, Invensis Learning's CSM Certification Training can help you master these concepts under expert guidance. Gain the globally recognized Certified ScrumMaster credential and the practical skills to lead Scrum Teams with confidence, from facilitating events to removing impediments and driving continuous improvement.
FAQs
1. What is the Scrum Guide?
The Scrum Guide is the official rule book that defines Scrum's core values, roles, events, and artifacts, first published in 2010 and updated several times since. It is maintained by Scrum creators Ken Schwaber and Jeff Sutherland and is freely available to anyone looking to understand or apply the Scrum framework.
2. What changed in the 2020 Scrum Guide?
The 2020 Scrum Guide merged the Development Team and Product Owner into a single, unified Scrum Team to eliminate the "us and them" divide that existed in earlier versions. It also introduced a formal commitment for each artifact, the Product Goal for the Product Backlog, the Sprint Goal for the Sprint Backlog, and the Definition of Done for the Increment, adding sharper focus and transparency throughout the Sprint.
3. What are the three pillars of Scrum?
The three pillars are transparency, inspection, and adaptation. Together, they support empirical process control by ensuring work is visible to everyone involved, regularly inspected for problems, and adjusted quickly whenever something deviates from the expected outcome.
4. What are the roles in a Scrum Team?
A Scrum Team consists of Developers, a Product Owner, and a Scrum Master, with no sub-teams or hierarchies within the group. Developers build the product Increment, the Product Owner manages and prioritizes the Product Backlog, and the Scrum Master helps the team and organization understand and apply Scrum effectively.
5. What are the events in Scrum?
Scrum includes four formal events within the Sprint: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective, with the Sprint itself acting as the container for all of them. Each event creates a regular opportunity to inspect progress and adapt the plan as needed.
6. What are the Scrum artifacts?
The core Scrum artifacts are the Product Backlog, Sprint Backlog, and Increment, each paired with a commitment (Product Goal, Sprint Goal, and Definition of Done) that adds transparency to the work. Related concepts like product vision, sprint vision, and burndown charts also support the Scrum framework, even though they are not always classified as formal artifacts.
7. How is the Scrum Master's role different in the 2020 Scrum Guide?
The 2020 Scrum Guide reframed the Scrum Master from a "servant leader" to "a leader who serves," emphasizing active leadership rather than a purely supportive function. The Scrum Master now has clearly defined responsibilities toward the Scrum Team, the Product Owner, and the broader organization, rather than being seen simply as a facilitator.
8. Is Scrum only used in software development?
While Scrum originated in software development, it is now applied across many domains involving complex work, including research, marketing, and product development more broadly. The Scrum Guide intentionally keeps the framework lightweight and generalized so it can be adapted to different organizational needs.
9. How do I become a certified ScrumMaster?
Becoming a certified ScrumMaster typically involves completing an accredited training course that covers the Scrum framework, roles, events, and artifacts in depth, followed by passing a certification exam. Invensis Learning's CSM Certification Training is one option that provides structured, expert-led preparation for this credential.
