In part 1 of the article, I was presenting the Scrum roles. Now I’d like to describe Scrum events, for example, events occurring at a specific time frame, necessary to work in the Scrum framework. I will also explain what the artifacts in Scrum are.

What events occur in Scrum?

 

Sprint

Sprint is a time frame that usually lasts 2 or 3 weeks, no more than a month. The result of a sprint is possible product growth. In other words, like a sprint, we define any period – a week, two weeks, twenty days, no longer than one month at the end of which we have a version of a product ready to publish (in a production environment).

A sprint that has already started cannot be shortened or extended; only in exceptional cases. The Product Owner can stop the sprint when its goal becomes obsolete, for example, by changing business requirements.

Sprint planning

Sprint planning is an event for members of the Scrum team lasting no more than 8 hours for a one-month sprint. During this meeting, they discuss the work that has to be performed based on the Product Backlog elements prepared by the Product Owner. Then they set a clear goal that will guide the team during the ongoing sprint to direct them on the right path and to understand together what to do. They plan work that the development team declares to do by creating a Sprint Backlog explaining also how the work will be delivered.

 

Daily Scrum

The so-called DS is an event organized by and for members of the development team, taking place every day and lasting no more than 15 minutes. During it, members summarize the recently completed work and plan tasks for the next day.

This is not a status meeting to control the teamwork. Its purpose is to check (inspect) whether the team is moving in the right direction to achieve the assumed goal of the sprint, and whether there are no blockages or problems that may cause difficulties in achieving this goal and planning the next work.

Sprint Review

The sprint review always takes place at the end of the sprint and lasts no more than 4 hours for a one-month sprint. The Product Owner organizes it for the Scrum team and stakeholders. Its purpose is to inspect the increment made.

The scrum team shows to the stakeholders what has been done and collects feedback directly from them (their opinions, conclusions, proposals for further work, or changes). They discuss new jobs that can maximize the value of the product. Based on the information collected, the Product Backlog is updated. This meeting stimulates cooperation between the Scrum team and the stakeholders.

Sprint Retrospective

The last event I have to describe is a sprint retrospective. This meeting is organized after the sprint review but before the next planning. Members of the Scrum team participate in it, and the event itself should not last longer than 3 hours for a one-month sprint. During this meeting, the last sprint is discussed and analyzed in terms of people, relationships, processes, and tools. The team identifies essential elements that worked well, but also those that need improvement. It is recommended that at least one improvement goes to the Sprint Backlog.

Another aspect discussed is the Definition of Done. As in the previous case, the team is working on improving the Definition of Done to increase the quality of the product delivered. To sum up, the sprint retrospective focuses on people, their relationships, and processes within the team. The goal is to increase the quality of work and streamline teamwork.

 

What Artifacts occur in Scrum?

 

Increment

The increment is all the work done in a given sprint that must be consistent with the work done in previous sprints. Roughly translated, this is a new version of the software that includes improvements and new functionalities. Also, for an increment to be considered as made, it must meet the Definition of Done established by the Scrum team. It also has to be ready for publication, not requiring any additional work on it. If it still requires some testing, or bug fixes, the increment has not been done. It is the sole decision of the Product Owner whether the increment should be published or not.

Definition of Done

The Definition of Done describes the set of processes and works that must be performed to recognize that a given element of the Product Backlog or Growth is “done.” For example, this definition may (among other things) describe whether and what tests need to be performed, the course of acceptance, or publication. If an organization has its procedures for describing software development, the team should maintain its standard as the minimum necessary. Otherwise, they should describe their definition of done. As the team develops, their Definition of Done should also evolve, increasing the quality of the product delivered.

Product Backlog

This is a list of all functionalities, features, and requirements that should be worked on in the future. Only the Product Owner is responsible for it, defining the best-known and understood requirements. It should be ordered from the essential elements to those less critical or less known. This list is dynamic, continually changing, and evolving with the product.

Although the Product Owner is in charge of the Product Backlog, the help of the Scrum team can be used and, on PO’s recommendation, the Scrum team can also add or modify elements of the backlog.

The Product Backlog can contain anything: any idea, functionality description, user story, and every element that is important for the project. Until the element is not being added to the Sprint Backlog, it does not have to be clarified and defined. Being added, it should be described and defined so the development team can understand the element and its goal.

Sprint Backlog

Sprint Backlog is a set of all elements selected from the Product Backlog to be performed in a given sprint extended by the plan of their delivery and the purpose of the sprint. It contains elements understandable for everyone and estimated by the development team.

The development team is an owner of a Sprint Backlog. It means that the team decides whether a given task from the Product Backlog proposed by the Product Owner can be added to a given sprint and only they can make changes in the Sprint Backlog. Elements contained in it change with the course of the sprint, are added or removed by the development team as needed, and progress to achieve the sprint goal. Such changes can be done at any given time or during grooming sessions which should be short and efficient, so as not to disturb the team’s main goal.

Summary

Now we managed to reach the end of this primer. By knowing the roles, events, and artifacts in Scrum, the whole process should be much easier to understand. It’s easy to learn Scrum, but mastering it requires much more work.

One should understand why it should be carried out within the limits that impose, how changes adversely affect the whole process, and how to implement its assumptions. This is a topic for many more articles or even a book.