Definition of Scrum
Scrum (noun) is a framework (a set of basic elements and rules, a kind of framework on which the development process is built), which helps to solve tasks changing tasks in order to productively and creatively deliver products to customers with the highest possible value.
Scrum is:
- compact,
- simple to understand,
- difficult for perfect mastery.
Scrum is a process framework that was used to manage work on complex products in the early nineties. Scrum is not a process, a technique or an exhaustive method. On the contrary, Scrum is a framework in which you can use a variety of processes and methods. Scrum shows imperfection in product management and work methods so that you can constantly improve the product, team and work environment.
The main elements of the framework are the Scrum commands and related roles, events, artifacts and rules. Each element of the framework serves a specific purpose and is mandatory for the successful use of Scrum.
The rules of Scrum connect events, roles and artifacts together, regulate relations and interactions between them. They are described in this document.
There are various tactics for using the framework, but their description is beyond the scope of this document.
Scrum Applications
Scrum was originally developed for product management and development. Since the early nineties, Scrum has been actively used around the world to:
- to explore and identify viable markets, technologies and product capabilities;
- develop products and improve them;
- produce products and their updates several times a day;
- develop and maintain cloud technologies (online, secure, on-demand) and other environments for the use of products;
- maintain and update products.
Scrum was used to develop software, hardware, firmware, autonomous vehicles and microbiological research. Scrum was used in schools, government, marketing, in the management of organizations - everywhere and every day in the lives of individuals and communities.
In today's world, the complexity of technologies, the behavior of markets and the environment, and their interaction have dramatically increased. In these conditions of complexity and uncertainty, Scrum daily confirms its usefulness and the need for application.
Scrum has proven to be particularly effective in iterative and incremental knowledge transfer. It is widely used in work on products, services and in the management of organizations.
The essence of Scrum is a small team of people. Each individual team is extremely flexible and adaptive. These advantages are manifested by extending to any number of teams in the organization: one, several or entire teams' networks that develop, produce, operate and support products, thus uniting the work of thousands of people. They work together and interact with advanced architectures and modern environments for release. When the words "develop" and "develop" are used in the Scrum Guide, they mean a complex work involving the types listed above.
Theory of Scrum
Scrum is based on the theory of empirical control (empiricism). According to this theory, the source of knowledge is experience, and the source of decisions is real data.
Scrum uses iterative (regular repetition of the full cycle of work on the product with continuous analysis of the results of the previous stage and adjustment of requirements and process) and incremental (incremental results of the previous stage) approach to improve predictability and manage risks. The process of empirical management is based on "three pillars": transparency, inspection and adaptation .
For example, air conditioning, operates on the principle of empirical control. It regularly measures the room temperature (carries out an inspection) and, if the temperature exceeds the preset mark, turns on the cooling mode (adapts). At the same time, it is important that the temperature sensor works properly and correctly shows the temperature (providing transparency).
Transparency
"Transparency" means that the significant characteristics of the process should be known to those responsible for its outcome. Transparency requires: these characteristics should be identified by common agreements, so that all participants understand the same.
For example:
- terminology relevant to the process should be common to all participants.
- an understanding of the Willingness Criteria6 should be common to the performers and those who inspect the results.
Inspection
Participants in the process should regularly inspect the Scrum artifacts and their progress towards the Sprint Objective in order to detect unwanted deviations in time. The frequency of inspections should not interfere with work. Checks are most beneficial when performed by professionals with relevant skills.
Adaptation
If, as a result of the inspection, it turns out that one or more of the process characteristics are out of tolerance, and this leads the product into an unacceptable state, the process or the material being processed must be changed. The sooner the changes are made, the less risk of further deviations.
Scrum assumes four formal events for inspection and adaptation:
- Planning a Sprint ;
- Daily Scrum ;
- Sprint Review ;
- Retrospective of the Sprint .
These events are discussed in detail in the "Events of the Scrum" section.
Scrum values
When the Scrum team relies on Scrum values:
- devotion
- courage,
- focus,
- openness,
- and respect;
and separates them, and the "three whales" of the framework:
- transparency,
- inspection
- and adaptation
are realized and create an atmosphere of universal trust. The participants of the Scrum team investigate and comprehend these values as they work with the events, roles and artifacts of Scrum.
The success of using Scrum directly depends on how well people adhere to these values. Each participant is dedicated to the goals of the Scrum team. All have the courage to act correctly and work on solving complex problems. Each participant is focused on the goals of the Scrum team and on their achievement within the Sprint framework. Interested parties and the Scrum team agree to be open with each other in the work, despite the difficulties encountered. Participants of the Scrum team respect the professionalism and independence of each other.
Scrum command
The Scrum command consists of the Product Owner, the Development Team and the Scrum Master. Scrum commands are self-organizing and cross-functional. Self-organizing teams independently decide how to do their work, and do not follow external instructions. Cross-functional teams have all the necessary competencies to do the work and do not depend on people who are not part of the team.
The team model in Scrum is aimed at improving flexibility, creativity and productivity. Scrum teams proved their effectiveness for solving any complex problems and all types of work, as described above.
Scrum commands deliver the product iteratively and incrementally, making maximum use of the opportunities for receiving feedback. Due to the fact that the finished product is delivered incrementally, a workable and potentially useful version of the product is available at any time.
Owner of the Product
The Owner of the Product is responsible for achieving the maximum value of the product as a result of the work performed by the Development Team. Ways to achieve maximum value can vary and depend on the organizations themselves, the Scrum teams and specific people.
The owner of the Product is the only person who is responsible for managing the Product Backlog. Management of the Product Backlog includes:
- a description of the Product BacLog Elements in a clear and understandable manner;
- managing the order of the Product BacLog Elements for the best achievement of goals and missions;
- Optimizing the value of the work performed by the Development Team;
- ensuring accessibility, transparency and clarity of the Product Baclog for all participants in the process. The product backlog at the same time reflects on what the Scrum team will work on;
- A guarantee that the Development Team understands the Product Backlog Elements sufficiently.
The Owner of the Product may perform this work independently or delegate it to the members of the Development Team. Nevertheless, the responsibility for the Product Backlog lies on the shoulders of the Product Owner.
The role of the Product Owner is performed by one person, not by a group of people. The Owner of the Product may reflect the wishes of the interested parties in the Product Backlog, but anyone who wants to change the priority of the item must contact the Product Owner.
For successful performance of duties by the Owner of the Product, all employees of the organization must respect his or her decisions. The decisions made by the Owner of the Product are reflected in the content and order of the Product Backlog Elements. Nobody can force the Development Team to work on another set of requirements.
Development Team
The Development team consists of professionals who are working to deliver the ready-to-grow Product Increment to the end of the Sprint. The increment must be ready for the Sprint Survey. Creation of the Increment is carried out only by members of the Development Team. Organizations form the Development Teams and give them all the powers to independently organize and manage their work. As a result, there is synergy, which increases the efficiency and productivity of development teams.
Development teams have a number of characteristics.
- They are self-organizing: no one (even the Scrum Master) can not tell the Development Team how to turn the Product Backlog into production-ready increments.
- They are cross-functional: the team has all the skills necessary to create a Product Increment.
- The developer is the only role for the Development Team members, regardless of the type of tasks that it performs. Scrum does not recognize other roles in the Development Team, this rule has no exceptions.
- Scrum does not recognize subcommands in the Development Team, regardless of the areas to be worked on (for example, testing, architecture, operation or business intelligence). This rule has no exceptions.
- The Development team has a collective responsibility for creating the Product Increment. Individual members of the Development Team may have different specialized skills and expertise.
Team Size Development
The optimal size of the Development Team is small enough that the team remains flexible, and large enough to perform meaningful work during the Sprint time.
When there are fewer than three people in the Team, the interaction and performance is reduced. Small Development Teams may encounter a lack of skills to create a ready-to-grow Product Increment. Teams with the size of more than nine people have difficulty in coordinating work. The complexity of working in large Development Teams increases so much that the empirical process becomes inapplicable.
When counting the number of the Development Team, the Product Owner and the Scratch Master are not counted if they do not themselves perform work from the Spring Sprint.
Scrum Master
The Scrum Master is responsible for promoting and supporting Scrum in accordance with the Scrum Guide. He achieves these goals by helping everyone understand the theory, practices, rules and values of Scrum.
Scrum Master is the servant leader for the Scrum Team. To people outside the team, it helps to understand that from their interactions with the Scrum team it is useful and what is not. The Scrum Master helps to change these interactions so that they maximize the value that the Scrum team creates.
Ken Blanchard in his book "Leadership to the heights of success" introduced the term "leader-servant". It means that the Scrum Master is not a privileged power carrier, as is the case with classical management, but a leader who involves the members of the Scrum team in the work process without formal power.
Scrum Master Services for the Product Owner
The Scrum Master provides the following services to the Product Owner:
- Provides the conditions under which the Scrum team understands the goals, scope of work and subject area as best as possible;
- helps to find the most effective techniques for managing the Product Backlog;
- explains to the Scrum-team the need for concise and understandable Bclong Product Elements;
- explains the features of product planning in an empirical environment;
- helps the Product Owner to streamline the Product Backlog in order to obtain the maximum value of the product;
- contributes to a better understanding of flexibility and its application;
- Facilitates Scrum events if necessary.
Facilitation is the organization of the group work process, aimed at facilitating the achievement of the goals set by the group.
Services Skrammasters for the Team
Scrum Master provides services to the Development Team:
- coaches the Development Team to be self-organizing and cross-functional;
- helps the Development Team create products with high value;
- Eliminates obstacles that impede the progress of the Development Team;
- facilitates the events of Scrum, if necessary;
- coaches the Development Team in those parts of the organization in which Scrum is not fully understood and accepted.
Coaching - The International Coaching Federation (ICF) defines coaching as a partnership that stimulates the work of thought and the creativity of the client, in which, with the help of the coach, he maximizes his personal and professional potential.
Services Scrumsmasters for the Organization
Skrammaster provides services to the Organization:
- directs and coaches the organization when implementing Scrum;
- plans to transition to Scrum in the organization;
- helps employees and stakeholders understand the theory and practice of Scrum, correctly implement the principles of empirical product development;
- contributes to changes aimed at increasing the productivity of Scrum teams;
- collaborates with other Scrum masters to improve the effectiveness of Scrum in the organization.
Scrum Events
Required Scrum events are provided to ensure that the process is regular, and other meetings would not be needed. Each event is limited in time and can not exceed the maximum set duration. The duration of the Sprint can not be changed after it starts. Other events can be completed ahead of schedule, if the objectives of the activities are achieved. This avoids wasting time.
Each event in the Scrum (except Sprint) is a formal opportunity for inspection and adaptation. Sprint is an exception, it is the container for other events. The events were created specifically to ensure maximum transparency and inspection. Rejection of any of them leads to a decrease in transparency and is a missed opportunity for inspection and adaptation.
Sprint
Sprint serves as the core of Scrum. Sprint - a time interval of a month or less, during which "Ready" is created, that is, the Product increment that is usable and released.
It is desirable to keep the Sprint's unchanged duration throughout the development process. The new Sprint starts right after the end of the previous one.
Sprint consists of Sprint Planning, Daily Scratch, development, Sprint Review and Sprint Retrospective.
During the Sprint:
- Do not allow for changes that could jeopardize the purpose of the Sprint;
- the quality of the product should not be reduced;
- as new knowledge arises, the scope of work can be refined and reconciled between the Product Owner and the Development Team.
Each Sprint can be considered a project that lasts no more than one month. Sprints, like projects, are needed to achieve goals. Each Sprint includes a goal, an implementation concept with an adaptive plan to achieve it, an executable work and a Product Increment as a result of the work.
Maximum Sprint duration is one calendar month. With a longer planning period, changes in goals, increased complexity, and increased risks are possible. Sprints help plan through the inspection and adaptation of progress towards the Sprint Goal at least once a month. They limit the cost of development risks by the month of work.
Sprint Cancellation
Sprint can be canceled ahead of time. The owner of the Product has the right to cancel the Sprint, although this decision may be affected by interested parties, the Development Team or the Scrum Master.
There is only one reason for canceling Sprint - the loss of the Sprint Sprint's relevance. The reason for this may be a change in the direction of the company, changes in market conditions or technology. That is, a sprint can be canceled if it has lost meaning in the context of the circumstances. But such cancellations occur extremely rarely due to the short duration of Sprints.
When Sprint is canceled, all completed and "Ready" Items of the Product Backlog are reviewed. The Owner of the Product accepts a part of the work representing the incremental release. All unfinished Product Backlog elements are revalued and returned back to the Product Backlog. Unfinished work on these Elements is rapidly losing value, so it needs to be reviewed and evaluated in new conditions.
Canceling a Sprint requires a lot of effort and resources, since it involves reorienting all the participants to start a new Sprint and its Planning. Sprint cancellations are painful for Scrum Teams, so they are rarely used.
Planning a Sprint
The tasks that the Development Team will work on during the Sprint are determined on the Sprint Planning. The plan is created by the joint efforts of the entire Scrum-Team.
Planning Sprint is time limited. For Sprint duration of one month Planning should not take more than 8 hours. If the Sprint is shorter, then Planning is faster.
Scrum-master is convinced that the event took place, and the participants understood its purpose. The Scrum Master instructs the Scrum Team to observe the time limit.
Based on the results of the Sprint Planning, the Scrum team decides:
- what will be the Increment at the end of the Sprint;
- how to organize the work to get the finished Product Increment.
Theme one: what will be done?
The Development team predicts the amount of functionality that will be developed during the Sprint. The Product Owner submits two important questions for discussion: the business objectives to be achieved in the Sprint, and the Product Backlog Elements required to achieve the Sprint's Goal. Based on these data, the Scrum Team forms a unified understanding of all the work in the Sprint.
To implement the Sprint Planning, you need: Product Backlog, the latest Product Growth, the Probability of the Future Development Team, Sprint, the statistics of its past performance. In this case, only the Development Team determines the number of Product Backlog Elements that can be executed in the Sprint. She also has the exclusive right to estimate the amount of work that can be completed in the current Sprint.
During the Sprint Planning, the Scrum team also forms the Sprint Goal. Sprint's goal is a necessary guide for the implementation of the Product BacLog Elements and helps the Development Team to better understand the purpose of the Increment.
Topic two: how will the work be done?
When the Sprint Object is defined and the Product Backlog Elements are selected, the Development Team decides how to implement this functionality in the form of a finished Product Increment during the Sprint. Selected Product Backlog Elements and a plan for their implementation are called the Sprint Backlog.
Drawing up a work plan in the Sprint Development team usually begins with the organization of the system and the work necessary to transform the Product Baclog to a fully-prepared Increment.
The work can vary in size and complexity, so the Development Team plans a sufficient amount of tasks, which, in its opinion, will be completed for the upcoming Sprint. Often by the end of the Sprint Planning, the Development Team more thoroughly details the work that will be performed in the early days of the Sprint. To do this, it divides the work into smaller tasks, usually lasting no more than one day.
The Development team is self-organizing both during the Sprint and during its Scheduling while working on the Sprint Backlog.
The Owner of the Product helps to clarify the meaning of the selected items. If the Development Team gets too much or too little work, then the Product Owner may compromise. Then the Development Team together with the Product Owner corrects the number and composition of the selected Product Backlogs to achieve the planned Sprint Goal. To obtain additional information in the subject or technical fields, the team can invite outside experts to consult.
At the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and the Scratch Master how it intends to work within the framework of self-organization to achieve the Sprint Goal and create the expected Increment.
Sprint's Goal
Sprint's goal is a benchmark set for Sprint, which is achieved through the execution of a part of the Product Backlog. The Sprint goal is formed during its Planning and explains to the Development Team, for which an Increment is created.
Sprint's goal leaves the Development Team with some flexibility in the amount of functionality that they develop within the Sprint framework. So the selected Product Backlog Elements can implement one related function, which is the Sprint Objective. Or Sprint's goal can be any other logical connection, for which the Development Team will work together, rather than being scattered over different tasks.
Sprint's goal is a benchmark for the Development Team. To achieve this, the team must use technology and implement functionality.
If the amount of work becomes different from the expectations of the Development Team, the team agrees with the Product Owner about the volume of the Bacloga of the current Sprint.
Daily Scrum
The Daily Scrum is a meeting of the Development Team, which is held every day during the Sprint. The meeting should not take more than 15 minutes, for which the Development team plans its work for the next 24 hours. The team optimizes the interaction between its members and improves their productivity, analyzing what was done in the last 24 hours and predicting the remaining work for this Sprint. For simplicity, Daily Scrum is performed every day at the same time.
Only members of the Development Team take an active part in the Daily Scrum. The remaining members of the Team Scrum can be present, however their participation is not necessary.
The Development team uses this event to inspect their progress towards the Sprint Objective and track progress on work on the Sprint Backlog, as well as to see if it is in time to complete Sprint's tasks on time. Carrying out the Daily Scrum increases the likelihood that the Development Team will achieve the Sprint's Goal. Every day, the Development Team members must understand how they are going to work together as a self-organizing team to achieve the Sprint Goal and create the expected Increment by the end of the Sprint.
The team itself determines the format of the meeting, but the emphasis is always on achieving the Sprint Objective. Some teams will hold a discussion, some will use questions, for example:
- What did I do yesterday that helped the Development Team approach the Sprint Objective?
- What will I do today to help the Development Team achieve the Sprint Goal?
- Do I see any obstacles that might prevent me or the Development Team from achieving the Sprint Objective?
Often right after the Daily Sprint, the Full Development Team or its individual members meet for more detailed discussion, or for changing or rescheduling the remaining work in the Sprint.
The Scrum Master keeps track of the Development Team meeting, but the team itself is responsible for conducting the Daily Scrum. The Scrum Master instructs the Development Team to run the Daily Scrum in 15 minutes or faster.
The Daily Scrum is an internal meeting of the Development Team. If someone else is present on it, Scrum Master keeps them from interfering with the meeting.
The daily Scrum improves communication, makes other meetings unnecessary, helps to identify obstacles in the development that need to be eliminated. It promotes and encourages rapid decision-making, raises the level of knowledge of the Development Team.
This is the key meeting for Inspection and Adaptation.
Sprint Review
The Sprint Review is conducted at the end of the Sprint for the purpose of inspecting the Increment and, if necessary, adapting the Product Balkog. The Scrum team and stakeholders during the Sprint Review jointly discuss what was done for the Sprint. These data, as well as any changes to the Product Baclog during the Sprint, serve as a basis for discussing the following steps to optimize the value of the Product.
The Sprint Review is not a status meeting, but an informal one. It demonstrates the Product Increment to receive feedback and develop cooperation. For Sprints for a duration of one month, the duration of the meeting does not exceed 4 hours. The shorter the Sprint, the shorter his Survey.
Scrum-master takes care of the meeting to take place, and all participants understand its purpose. Scrum-master teaches all participants to keep within the allotted time for the event.
Key elements of the Sprint Review:
- the number of participants in the meeting includes the Scrum team and key stakeholders who are invited by the Owner of the Product;
- The owner of the product explains which Balkord Elements are ready and which are not;
- The Development team talks about what happened during the Sprint, what problems there were and how they were solved;
- The Development team demonstrates a ready-made job and answers questions about the Increment;
- The Product Owner describes the current state of the Product Backlog. If necessary, he forecasts possible dates for the completion of the development of the Product, based on current indicators of progress;
- all present are discussing what it is worth working on next. Thus the Sprint Review provides valuable data for the next Sprint Planning;
- an overview is given of how changes in the market or the potential use of the product could change what needs to be done first;
- the terms, budget, opportunities and market positions are reviewed for future releases or product opportunities.
The result of the Sprint Review is a revised Product Backlog. It includes elements that can enter the next Sprint. Also, the Product Backlog can be changed if new business opportunities have appeared.
Retrospective of the Sprint
Retrospective of the Sprint is an opportunity for the Scrum team to conduct an inspection aimed at themselves, and create a plan for improving teamwork in the next Sprint.
The Sprint retrospective is held after the Sprint Review and before Planning for the next Sprint. The maximum duration of a Retrospective is 3 hours for a Sprint lasting one month. For shorter Sprints, as a rule, less time is spent.
Scrum-master is convinced that the event is positive and productive, teaches all participants to keep within the allotted time for the event. He takes part in the Retrospective on a par with other members of the team, but continues to be responsible for the Scrum process.
Goals of the Sprint Retrospective:
- inspection of the past Sprint in relation to people, relationships, processes and tools. Detection and ordering of what went well and what needs improvement;
- creating an implementation plan for improvements in the process of the Scrum team.
Scrum-master encourages the Scrum-team to improve the development and practice process within the framework of the Sram-framework. It is necessary that in the next Sprint increase its effectiveness and get more satisfaction from their work. Each Sprint Retrospective Scrum team plans actions to improve the quality of the product, improving the workflow or adapting the Readiness Criteria, if necessary and does not contradict the product specification and organization standards.
By the end of Retrospect, the Scrum team must plan for specific improvements that it implements in the next Sprint. Implementing these improvements is the adaptation of the Scrum command. You can work on improvements at any time, Retrospective of the Sprint - a formal opportunity to concentrate on inspection and adaptation.
Scrum artifacts
Scrum artifacts reflect work or value. They provide transparency and create new opportunities for inspection and adaptation. Scrum artifacts are specially designed to provide maximum transparency of key information so that all participants in the process have the same understanding.
Product Backlog
The Product Backlog is an ordered list of known requirements for the product. This is the only source of requirements for any necessary changes in the product. The Owner of the Product is responsible for the Product Backlog, including its contents, availability and orderliness.
The product backlog is never complete: at an early stage it contains only the initially known and most understandable requirements. The product backlog evolves along with the product and the environment in which it will be used. To keep the product up-to-date, competitive and useful, its Backlog constantly changes following the changes in the requirements to the product. While there is a product, there is also its Product Backlog.
The product backlog contains data that determines the need for changes in future releases of the product. Such data may include new characteristics or new product features, requirements, information on ways to improve the product and eliminate defects.
Each Product Backlog element must contain a description, a position number in the Backlog, an estimate of the amount of work and value. The Product BacLog elements often contain test descriptions that will make sure the Element is complete when it is "Ready."
As feedback is received from the market, when the product starts to be used and it makes a profit, the Product Backlog becomes more and more comprehensive and exhaustive. Changes in business requirements, market conditions or technologies may lead to changes in the Product BacLog. Because requirements are constantly changing, the Product Backlog remains a living artifact.
If several Scrum commands work on one product, one Product Backlog is used to describe the forthcoming work. Thus its elements can be grouped by attributes.
Product Backlog Refinement ("PBR") is an activity aimed at clarifying, evaluating and ordering items in the Product Boclogue. This is a continuous process in which the Product Owner and Development Team discuss the details of the Product BacLog Elements, thereby verifying and revising these elements.
The Scrum team decides how and when the Product Backlog should be made. Usually this process takes no more than 10% of the available time of the Scrum command. At the same time, the Product Backlog Elements can be changed at any time by the Owner of the Product himself, or at his / her instruction.
Items at the top of the list are usually better detailed than the items at the bottom. The more detailed and clear the description of the Product Backlog Elements, the more accurate it can be to evaluate them. In turn, the lower the elements in the Product Backlog, the less detailed they are.
The elements of the Product Backlog, which the Development Team will be working on in the future Sprint, are worked out so that they can be realized during the time of one Sprint. These elements are considered "Ready" to be taken into the Sprint on Planning. This level of transparency in the Product Backlog Elements is achieved through the Product Back-up Update process.
The Development team is responsible for all task evaluations. The Owner of the Product can influence the evaluation by helping the Development Team to better understand the work and make a compromise choice, but the final assessment is given by those who do the work.
Tracking progress towards goals
At any time, the work remaining to achieve the goal can be summed up. The owner of the Product monitors the total amount of this work at least on each Sprint Survey, he compares it with the volume that remained on previous Sprint Reviews. This allows you to assess the progress of the planned work at the desired time and goal. This information is made transparent to all stakeholders.
Various practices can be used to predict progress, for example, burn-down diagrams, burn-up diagrams or cumulative flow diagrams. These techniques are useful, but they can not replace the importance of empiricism. In complex environments, it is not known what will happen ; making decisions that are forward-looking, can only be based on what has already happened .
Sprint Backlog
Sprint Sprint is a set of Baclong Elements taken in the Sprint, plus a plan to achieve the Sprint Objective and supply the Product Increment.
The Sprint Sprint is the forecast of the Development Team about which functionality will go into the next Increment and what work is needed to create the Ready Increment.
The Sprint backlog reflects the entire amount of work that the Development Team considers necessary to achieve the Sprint Goal. To ensure continuous improvement, the Sprint Backlog contains at least one priority improvement chosen during the previous Sprint Retrospective.
The Sprint backlog is a fairly detailed plan, so progress can be determined within the framework of the Daily Scrum. The Development team changes the Sprint Backlog during the entire Sprint, so the Sprint Backlog clears up. This happens as the Development Team works on the plan and learns new details about the work necessary to achieve the Sprint Goal.
As the new work appears, the Development Team adds it to the Sprint Backlog. When part of the work is completed and completed, the evaluation of the remaining work is updated. In this case, the Elements of the plan can be deleted if the team believes that they have lost relevance. During the Sprint, the Sprint Backlog can only be modified by the Development Team.
The Sprint backlog belongs exclusively to the Development Team and serves as a visual representation of the actual amount of work the Development Team plans to accomplish during the Sprint.
Tracking the progress of the Sprint
The amount of work remaining in the Sprint's Bacloga can be calculated at any time. To assess the likelihood of achieving the Sprint Objective, the Development Team keeps track of the amount of work remaining at least on each Daily Scrame.
Increment
The increment is the sum of the Product BacLog Elements completed during the Sprint and all increments of the previous Sprints.
By the end of the Sprint, the Increment must be "Ready", which means that it meets the Scrum Team Readiness criteria and is ready to use. An increment is a collection of work performed that supports an empirical approach and which can be inspected at the end of a Sprint. An increment is a step towards a vision or goal. It must be ready for use, regardless of the positive or negative decision of the Owner of the Product on its release.
Transparency of Artifacts
Scrum relies on transparency. Decisions on obtaining optimal value and risk management are based on the state of artifacts. Full transparency of artifacts allows you to make reliable decisions. Incomplete transparency of artifacts leads to erroneous decisions, decreasing value and increasing risks. To understand whether the artifacts are completely transparent, the Scrum Master must cooperate with all the parties involved: the Product Owner, the Development Team and others.
There are practices to combat incomplete transparency, the Scrum master must help everyone to implement the most appropriate ones, if full transparency is not available.
A scrum master can detect incomplete transparency by inspecting artifacts, understanding patterns, attentively listening to the definitions of the differences between expected and real results.
The task of the Scrum Master is to increase the transparency of the artifacts, working with the Scrum team and the organization. This work usually involves training, persuasion and organizational change. Transparency does not appear overnight - this is the way to go.
Availability Criteria
When the Product Backlog Element or the Increment is described as "Ready", everyone in the team must understand what exactly "Ready" means. Although understanding, under what conditions the work is performed, can significantly differ from the team to the team, it must be the same for all participants in the same Scrum team. This is necessary to ensure transparency.
The decision on the readiness of the Product Increment is made based on the Availability Criteria adopted by the Scrum team. The same criteria help the Development Team during the Sprint Planning to determine how many Product Baclog's Elements it needs to take into operation.
The goal of each Sprint is to ensure the Increment of the potentially ready-to-release functionality of the product, corresponding to the current Availability Criteria adopted by the Scrum team. The Development team delivers an Increment of product functionality each Sprint. Because this Increment is potentially ready to use, the Product Owner may decide to immediately release it.
If the company adopted a single standard of the Availability Criteria, all Scrum teams should follow it. Otherwise, the Development Team shall independently determine the Availability Criteria appropriate to its product. If there are more than one Team Scrum running over the release of one system or product, then their Development Teams must jointly develop the Availability Criteria.
Each increment is added to all previous increments and thoroughly tested to ensure that all increments work together.
As the Scrum team becomes more mature, the Availability Criteria are likely to become stricter, providing a higher quality of the product being developed. The application of new criteria may lead to the fact that in the already taken "Ready" Increments work will be found that will need to be performed.
Any system or product must have a Availability Criteria, this is a mandatory standard for any work performed within this system or product.
Conclusion
Using Scrum is free. A detailed description of the framework is provided in this Guide. Roles, artifacts, rules and events of Scrum are not subject to change. Although the use of individual elements of this framework is acceptable, but the result can not be called Scrum. Scrum exists only as an integral framework, but it can contain other techniques, methodologies and practices.
Thanks
Individuals
Among the thousands of people who contributed to the development of Scrum, it should be noted those who made the most significant contribution at the dawn of its formation: Jeff Sutherland worked with Jeff McKenna and John Scumniotales; Ken Schwaber, worked with Mike Smith and Chris Martin, together they worked on the creation of Scrum.
In the following years, many other people contributed to the development of Scrum. Without their assistance, Scrum would hardly have had a modern degree of sophistication.
History
Ken Schwaber and Jeff Sutherland worked on Scrum until 1995, when they made a presentation at the OOPSLA conference (Object-Oriented Programming Systems, Languages and Applications). This report reflected the knowledge gained over the years, and for the first time a formal definition of Scrum was given. The history of the development of Scrum can also be found in other materials. Here we note only those organizations that first tested it and made changes to the framework: Individual, Inc., Fidelity Investments and IDX (today GE Medical). The Scrum manual describes the framework in the form in which it was developed and supplemented by Jeff Sutherland and Ken Schwaber for more than twenty years. In other sources, you can find templates, processes and ideas that complement the framework. All these additions can increase productivity, value, creativity and job satisfaction.
© 2017, Ken Schwaber and Jeff Sutherland. It is offered for licensing under the terms of the Attribution Share-Alike license (distribution on the same conditions) of the Creative Commons Corporation; with the full text available at http://creativecommons.org/licenses/by-sa/4.0/legalcode , a short form of the text is available at https://creativecommons.org/licenses/by-sa/4.0/deed.ru . Using the Scrum Guide, you acknowledge that you have read, understood and agree to abide by the terms of the Creative Commons Attribution Share-Alike license agreement.