Events and Artifacts of Scrum
In the following, not only the most important events and artifacts of Scrum are explained, but also how they are connected to each other.
The Product Owner has a certain product vision. Because the product can be very complex, it is broken down by so-called backlog grooming into smaller features (elements) that are listed in a priority list, the product backlog.
A sprint begins with sprint planning, includes development work (sprint execution) during the sprint, and ends with review and retrospective. The number of points in the product backlog is usually higher than a development team could handle in a short sprint phase. Therefore, the development team must initially determine a number of points in the product backlog that it believes it can complete (Sprint Planning). The goal is to have a potentially deliverable product increment at the end of the sprint.
A remark on the side
In 2011 a change in “The Scrum Guide” (Schwaber and Sutherland 2011) has triggered a debate about whether the appropriate term to describe the outcome of Sprint Planning should be “forecast” or “commitment”. Proponents of the term forecast prefer this term because even the best estimate can change during a sprint due to new information. There is also the opinion that a commitment on the part of the team leads to the quality of the work suffering because an attempt is made to meet the set goal in any case, or because the team may tend to set goals that are too low for it to achieve in any case.
There is no question that every development team should make an assessment of what they think they can achieve in a sprint. However, many development teams could benefit from deriving a commitment from a forecast. Commitments lead to greater trust between the product owner and the development team, as well as between the individual members of the team. Commitments also facilitate short-term planning and meaningful decision making in an organization. When multiple teams are involved in product development, commitments enable them to better align their planning – one team can base its decision making on the commitment of another team. However, a commitment should be based primarily on the sprint goal and not so much on the open tasks. With increasing knowledge, teams often succeed in achieving the sprint goal in a different way than originally thought. (The term commitment is most often used in the following. However, if the context requires it, the term forecast is also used from time to time).
To ensure that the development team has made a meaningful commitment, team members create a second backlog during the course of sprint planning, also called a sprint backlog. This sprint backlog uses detailed to describe how the team plans to design, develop, integrate, and test the individual characteristics from the product backlog during this sprint.
The next step is called Sprint Execution. Here the development team performs the necessary tasks to implement the selected features. In this phase, there are daily scrums in which synchronization and verification activities as well as adaptive planning activities are performed. This enables the team members to better manage their workflows. At the end of the Sprint Execution, the team has produced a potentially deliverable product increment that already represents a part of what the Product Owner had in mind.
The Scrum team ends the Sprint with the inspect-and-adapt of the product and the Scrum process. The product is reviewed in the Sprint Review by the Scrum Team and the stakeholders. The review of the Scrum process used to create a product is done by the team members in a process called Retrospective. As a result, adjustments can be made in the Product Backlog or in the development process.
At this point the sprint cycle starts all over again. The development team now determines the next product backlog items that it can complete. After an appropriate number of sprints, the product owner’s vision will have been realized and the result can then be presented.
Each of these Events and Artifacts will be discussed in detail below.
Product Backlog
When working with Scrum, the most valuable work is always done first. The Product Owner – involving the development team and stakeholders – is ultimately responsible for the sequence of these work steps and has to communicate them in a priority list, the Product Backlog. In the development of new products, the Product Backlog Items are first of all only those features that are needed to realize the Product Owner’s vision. In the further development of products, the Product Backlog may also contain new features, as well as modifications of existing features, necessary repairs of defects or technical improvements, etc.
The Product Owner works with internal and external stakeholders to collect and determine the Product Backlog items. He must then ensure that all items are put in the right order (in terms of value, cost, knowledge and risk) so that the most valuable items appear at the top of the product backlog and the less valuable items further down. The product backlog is an ever-evolving artifact. If the circumstances for a company change or the Scrum team’s understanding of the product (through feedback during sprints) grows, items can be added, removed and revised by the Product Owner.
Basically, designing, working out, evaluating and prioritizing the Product Backlog Items is called Backlog Grooming or Backlog Refinement.
However, before you can complete the prioritization or ordering of items in the product backlog, you must first know the scope of the individual items. The scope determines the costs, and the product owner must know these in order to determine the priority of an item. Scrum does not specify a specific unit of measurement. In practice many teams use relative units of measurement such as Story Points or Ideal Days. A relative unit of measurement does not express the absolute size of an item, but only its size in relation to other items.
Sprints
In Scrum there are iterations or cycles of up to one month called Sprints. A completed sprint should always produce something of tangible value for the customer or user.
For all sprints there is a time frame (Timebox) with a fixed start and completion time, which should be the same for all sprints. The completion of a previous sprint is immediately followed by a new sprint. Even if there are changes to the scope of services or personnel that would affect the target and therefore should not actually be made during a sprint, this is sometimes unavoidable due to certain business needs.
Sprint Planning
The work in a product backlog can take several weeks or months, which is far more than can be accomplished in a single, short sprint. In Sprint Planning, the Product Owner, the development team and the Scrum Master determine which are the most important Product Backlog Items for the next Sprint. In this planning, the product owner and the development team agree on a sprint goal, that is, a definition of what is to be achieved in the following sprint. Based on this target, the development team reviews the product backlog and names the most valuable items that the team can actually complete in the next sprint. The working speed, also known as Sustainable Pace, should be chosen in such a way that it can be easily maintained for a long time.
To get a feel for what is feasible, many teams divide each Product Backlog item into different tasks. Together with the corresponding items, these form a second backlog, the sprint backlog.
The development teams then give an estimate of the effort required for each item (usually in hours). Splitting product backlog items into tasks is a form of design and just-in-time planning for feature completion. If the sprint lasts one to four weeks, the sprint planning should be completed in two to eight hours – that’s all the time you should allow for. There are several approaches to this, one of the most popular is based on a simple cycle: You select a product backlog item (if possible, the next item in the product owner’s ranking), divide it into tasks and decide whether it fits well into the sprint (with regard to other items that are intended for this sprint). If it fits into the sprint and there is enough time left, the process is repeated until the team’s capacity for further tasks is exhausted.
In a further procedure, the product owner and the team determine all desired product backlog items at once. Only the development team performs the split into individual tasks, thereby confirming that it can complete all desired items.
Sprint Execution
Once the Scrum team has completed Sprint Planning and agreed on the content of the next Sprint, the development team sets about doing the work (at the task level) necessary to complete the features. Completion in this case means that all work necessary to produce high quality features has been done.
No one tells the development team how and in what order to do the work in the sprint backlog at the task level. This allows team members to define their own task level work and organize themselves in the way they think is best for achieving the sprint goal.
Daily Scrum / Daily Standup
Every day during the sprint, preferably at the same time and place, the team members hold a meeting called Daily Scrum. This meeting should last a maximum of 15 minutes. This Inspect-and-Adapt process is sometimes called Daily Stand-Up, because in practice everyone present often stops to keep the meeting short.
A common procedure for Daily Scrum is that each team member answers three questions, which is very helpful for the rest of the team.
- What have I achieved since the last Daily Scrum?
- What do you think I will work on in the next Daily Scrum?
- What exactly is stopping me from making progress?
By answering these questions, everyone gets an overview of what is happening, the progress towards the sprint goal, what changes in the plan for the next day and what issues need to be addressed. A Daily Scrum is essential to ensure that the team can work quickly and flexibly in a Sprint.
Problems are not solved in the Daily Scrum. Instead, after the Daily Scrum the teams can meet with all interested people in small groups to discuss problems. The Daily Scrum Meeting is also not a traditional status meeting like those that are called by a project manager to inform him about the latest state of the project. A Daily Scrum is rather meant to communicate the status of Sprint Backlog Items within the development team. Mainly, a Daily Scrum is an activity where checks, synchronizations and adaptive planning are performed, allowing a self-organized team to do an even better job.
Definition of Done
In Scrum the results of the sprints are called potential deliverable product increments. This means that everything that the Scrum team wanted to create was done according to the agreed Definition of Done (definition of what can be considered done). This definition specifies the degree to which the result of the work is also of good quality and potentially deliverable. In the development of software, for example, the Definition of Done should specify, as an absolute minimum, the complete development of a product function which is designed, developed, integrated, tested and documented.
An aggressive Definition of Done allows a company to decide at each sprint whether to deliver what has been developed to internal or external customers.
Just to understand: “potentially deliverable” does not mean that something actually has to be delivered. This is a business decision that is constantly influenced by factors such as “Do we have enough features or have we done enough to satisfy the customer” or “Can our customers tolerate another change if we delivered something to them two weeks ago?
“Potentially Deliverable” should rather be seen as the degree of what was actually accomplished in the Sprint. This means that no important work (such as important testing or integration, etc.) is left unfinished and needs to be completed before the Sprint result could be delivered. The Definition of Done is not set in stone and, like everything else, should be subject to regular review and adjustment. In practice, many teams change their Definition of Done over time.
Sprint Review
At the end of each sprint there are two more Inspect-and-Adapt activities. One of these is called a Sprint Review.
The goal of this scrum event is to review and adapt the desired product. An essential part of this is the communication between the Scrum Team, stakeholders, sponsors, customers and interested members of other teams. The focus is on checking the features that have just been completed with regard to the overall development effort. Everyone present gets a clear idea of what is going on and has the opportunity to influence further development to enable the best solution for the company.
A successful review results in a flow of information in both directions. The people who are not in the Scrum team can get information about the status of the product and influence the next steps. At the same time, the members of the Scrum Team have the opportunity to develop a better understanding of the business and marketing aspects by getting constant feedback on whether the product development is on the way to making customers and users enthusiastic about the product. So the Sprint Review is a planned opportunity to review and adapt a product. People outside the Scrum Team can conduct feature reviews during a Sprint and give feedback, which in turn helps the Scrum Team to achieve its Sprint goal.
Sprint Retrospective
The second Inspect-and-Adapt event at the end of a Sprint is the Sprint Retrospective and is regularly performed after the Sprint Review and before the next Sprint Planning. While a Sprint Review is used to review and adapt a product, the Sprint Retrospective is an opportunity to review and adapt the process. During a Sprint Retrospective the development team, the Scrum Master and the Product Owner come together and discuss what works and what doesn’t in practice with Scrum. The focus is on the continuous improvement of the process by which a good Scrum team can become a great Scrum team. At the end of a Sprint Retrospective the Scrum Team should identify a meaningful set of improvement actions that they will then implement in the next Sprint.
When the Sprint Retrospective is over, the whole process starts all over again – starting with a new Sprint Planning where the most valuable work on which the team has to concentrate is determined.