In previous article we’ve learned about members and process in Scrum. Now let’s talk about artifacts which compose Scrum and what rituals are necessary to follow during the work on a project.

Artifacts in Scrum

One of the main tools of PO is Product Backlog. There are 2 types of backlogs: Product backlog and Sprint backlog.

Product Backlog is a complete list of all the works, in the implementation of which we will get the final product. All requirements are described by a single template, which is called the User Story. The requirements are formulated so that it is obvious and understandable what value they represent to the user. The requirements are sorted by priorities, which are revised for each sprint.

Sprint Backlog is a list of works, which the team determined and agreed with the Product Owner for the next reporting period (sprint). Assignments to the Sprint backlog are taken from the Product backlog. During the sprint, new requirements can not be added to the Sprint backlog. All requirements should be divided into tasks and estimated.

Sprint Goal is a short description of what this sprint is for. The goal for the sprint helps the team make informed decisions. This artifact is necessary in order that the project team could make their own decision in the case of alternative ways of solving the problem. To make team decisions conscious, the Product Owner determines the purpose of the sprint.

In the Sprint Burndown Chart, the man-hours or ideal units (Story Points) are used as burning elements. The chart is updated every time when a task is completed.

Rituals in Scrum

There are several processes in the Scrum, which are called rituals. Each ritual is carried out rigorously and in strict accordance with the approach. In practice, such processes tend to adapt a little, but the key principles do not change.
Rituals in Scrum are:
-Sprint Planning Meeting
-Daily Meeting
-Sprint Review
-Retrospective

Sprint Planning Meeting is a meeting where everyone is present (Development Team, Scrum Master, Product Owner). During this meeting, the Product Owner determines the priorities of the tasks that he would like to see completed after the sprint. The team evaluates by the time how much of the desired they can perform. The result is a list of tasks that can not be changed during the sprint and must be fully executed by the end of the sprint.

Backlog is needed if you want to take into account the interrelation between the operations. The command decomposes the requirements into tasks, each task is evaluated in labor or universal units. During the meeting, the Product Owner answers the team’s questions.

The structure of the meeting:
-representation and explanation of the Product Owner’s list of requirements
-queries from the team
-decomposition of requirements for tasks
-evaluation of tasks using the Planning Poker method.

The meeting is simple in nature, but extremely difficult in content. At the beginning of the project may take 5-6 hours. And only after 3-4 sprints the meeting becomes more operative and lasts 2-3 hours.

Daily Meeting. From the title it is clear that the meeting is held daily. Basic principles:
-runs daily and only at the same time;
-everyone at the meeting are standing;
-the meeting does not last more than 15 minutes;
-to catch the meeting everyone should answer only 3 questions: what I did yesterday, what I’m doing today, what are the problems?

Scrum Master monitors the course of the meeting, encourages participants to speak out completely and listen to the speaker.

At a daily meeting, the team exchanges experience. It also becomes clear who will work on what tasks. It is important that the team does this ritual on their own.

It is recommended that the Scrum Master not interfere in the meetings as long as all the requirements for this ritual are met.

The meeting of the team is effective to conduct in front of the Kanban board, which reflects all the tasks of the sprint.

Sprint Review – Delivery of Sprint to Product Owner. At the end of each sprint, the team must demonstrate the result.

The value of Scrum for a typical customer is largely that the result of the work (bad or excellent, not important) will be demonstrated in any case. This is known to both the team and the Product Owner and other interested parties. If the team does not conduct a demonstration (otherwise called Sprint Review), then it discredits all the benefits of flexible processes.

The structure of the meeting:
-the team reads the requirements from Sprint Backlog
-for each acceptance criterion, the results are shown
-any question from the Product Owner is noted in order to be able to answer them later
-each new Product Owner’s requirement is issued to be added to the Product Backlog later.

Any employees or simply interested persons can attend the meeting. It is important that only participants of the Scrum process (Product Owner, Team, Scrum Master) have the right to vote.

Retrospective. A ritual, which is aimed at sharing experiences within the team. The meeting is held after the Sprint Review. At the meeting there is a whole team and Scrum Master. The meeting may be attended by the Product Owner, if it deems it necessary.

The methodology of the meeting varies depending on the project, the team and the traditions in the team. Nevertheless, the following questions should be answered:
-what decisions should the team take to make the process more predictable?
-what problems prevent the team from fulfilling its obligations?
-how to improve the interaction with the Product Owner?
-what mistakes the team makes and why.

Solutions must be written on a separate board. After a general vote, decisions are taken for execution from the next sprint. Scrum Master controls the course of the meeting and monitors its regulations.

Advantages and disadvantages

Scrum has quite attractive advantages. Scrum is customer-oriented, adaptive. Scrum allows the client to make changes to the requirements at any time (but does not guarantee that these changes will be made). The ability to change requirements is attractive to many software customers.

Scrum is quite easy to learn, it saves time by eliminating non-critical activities. Scrum allows you to get a potentially working product at the end of every Sprint.

Scrum focuses on a self-organizing, multifunctional team that can solve the necessary tasks with minimal coordination. This is especially attractive for small companies and startups, as it eliminates the need for hiring or training of specialized management staff.

Of course, Scrum has important drawbacks. Because of its simplicity and minimalism, Scrum sets a small number of fairly strict rules. However, this conflicts with the idea of customer-centricity in principle, since the internal rules of the development team are not important to the client, especially if they restrict the client. For example, if necessary, according to the client’s decision, Sprint backlog can be changed, despite the obvious contradiction with Scrum rules.

The problem is larger than it appears. Due to the fact that Scrum belongs to the Agile family, it does not accept, for example, the creation of a communication plan and a response to risks. Thus, making it difficult or impossible to formal (legal or administrative) opposition to violations of Scrum rules.

Another weak feature of Scrum is a focus on self-organizing, multi-functional team. With an apparent reduction in team coordination costs, this leads to higher costs for staff selection, motivation, training. Under certain conditions of the labor market, the formation of a full-fledged, effective Scrum team may be impossible.