Scrum for beginners: Part 2: Scrum events, scrum artifacts
In the previous article. I have already presented Scrum roles. The next topic I will present will be Scrum Events, i.e. events occurring at a specific time frame, necessary to work in the Scrum Framework. At the end I will explain what are Artifacts found in Scrum. As the definition implies, these are works of the Scrum team that you can learn more about below.
What events occur in Scrum?
The first event I will discuss is Sprint. This is a time frame of no more than one month, which results in 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 ready for publication (on production enviroment) Increment of the product (new version). There are other Scrum events as part of the Sprint.
A sprint that is 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.
This is an event lasting no more than 8 hours for a one month sprint for members of the Scrum team. During this meeting, discussing the work to be performed based on the Product Backlog elements prepared by the Product Owner. Then they set a clear goal for the Sprint 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 it will deliver work.
The so-called DS. It 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 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 prevent achieving this goal and planning the next work.
The sprint review always takes place at the end of the Sprint and lasts no more than 4 hours for a sprint lasting a month. The Product Owner organizes it for the scrum team and stakeholders. Its purpose is to inspect the increment made.
The scrum team presents stakeholders with what has been done and collects feedback directly from them in the form of opinions, conclusions, proposals for further work, or changes. New jobs are discussed 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 stakeholders.
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 monthly 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 have 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 thinking and 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?
The first artifact I discuss is Increment. This is all the work done in a given Sprint, which must be consistent and complete 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 Increment to be considered as made, it must meet the Definitions of Done established by the scrum team. It must also be ready for publication, not requiring any additional work on it. If it still requires some testing, bug fixes, that means the Increment has not been done. Whether the Increment should be published or not, is sole decision of the Product Owner.
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." I describe it so that everyone has a consistent understanding of when a part can be considered complete. 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 define their definition of done.
As the team develops, their Definition of Done should evolve and develop, increasing the quality of the product delivered.
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, where it defines 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 chargé of product backlog, he can use help of the scrum team and, on his recommendation, they can also add or modify elements contained in it.
The Product Backlog can contain anything, any idea, functionality description, user stories, which are important for the project. Until the element is not being added to the Sprint Backlog, it does not have to be clear and defined. As product progress, the Backlog elements should be worked on and clarified. So the development team understands them and their goal.
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. Contains understandable for everyone involved and estimated, by development team, elements.
Its owner is the development team, which decides whether a given task proposed by the Product Owner from the Product Backlog can be added to a given Sprint and only they can make changes to the Sprint Backlog. Elements contained in it are not permanent, they 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 by any given time or during grooming sessions which should be short and efficient, to not to disturb teams main goal.
In this way, we managed to reach the end of this primer. I presented the roles, events, and artifacts in it, after which understanding what Scrum is should be much more comfortable. It's easy to learn, but mastering it to perfection requires a lot, 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 best to implement its assumptions. However, this is a topic for not one other entry, article, or book.