Sprint sets the beat for the Scrum team. What does the Sprint goal definition look like in practice, and what are the benefits of using it?
Referring to the generally available Scrum Guide, we understand Sprint as a time frame in which we have to deal with specific tasks. Because we have limited divisibility of attention, each stage of work should be separated. Objectives to achieve can be various, from testing the potential risk associated with the product to testing its functionality in various scenarios. Each stage facing the team is one sprint that lasts no more than a month.
The time required to perform specific tasks remains constant throughout the product development period. Sprints follow each other without major breaks, which is why they are cyclical. There is no question of downtime. At the same time, the Scrum Master must ensure that the team structure and quality guidelines remain unchanged during the sprint. It should be noted, however, that the scope of the Sprint is getting more precise as the progress is made.
We divide the sprint into: Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. Velocity also plays an important role, but focusing only on this parameter will have a negative impact on the quality. We will not mention the potential burnout or growing frustration. We avoid high thresholds as well as sudden spikes, because this will lead to unwanted friction within the team. The first step to success must be predictability and maintaining a balanced pace.
In case of an accident, when the chosen goals no longer make sense, the Product Owner has the possibility to cancel the sprint. His decision can be influenced by both Development Team and Scrum Master. This is a quite exceptional situation, in response to the inability to meet the submitted objectives. For example, when quality does not meet expectations.
Sprint Planning: the aim will be to identify new directions or, if necessary, to make some changes to existing activities. Each meeting has to answer the question: "what?" and then "how?". Initially, we define a project, tasks, descriptions of works, thus leading to the creation of a product register. During the meeting, team members determine how much work they have to do and whether the assumptions are realistic. In such a case, it is appropriate to discuss the scope of responsibilities with the Product Owner once again. When it comes to short Sprints, as a rule, no more than 5% of the total time is spent on planning.
Daily scrum: Before we start our daily duties, the team conducts fifteen-minute meetings throughout the Sprint. The meetings are always held at the same time and place. They must be concise and not exceed the time allowed, ensuring what the Scrum Master is doing.
Sprint Review: an informal meeting is held at the end of Sprint. This is the time to summarize the work done and to plan the tasks for the next Sprints. It is the responsibility of the Product Owner to evaluate the implemented solutions and to analyze the reasons why the tasks were not completed. Then the Product Owner suggests a probable date of completion of all the works. In short, the Sprint Review is a preparation for the next planning meeting of the Sprint.
Sprint Retrospective: takes place between the Sprint Review and the next Sprint Planning meeting. It cannot last longer than three hours. The Scrum Master moderates the discussion. During these meetings we look at what the last Sprint looked like, in terms of the relationships and contributions of the individual participants. The individual processes and the tools used are also evaluated. In this way, possible errors are detected.
Sprint Backlog is a list of tasks that a team must perform in a sprint. The registry entries will then be transferred to Product Backlog, based on the priorities submitted by the Product Owner. The team then selects the sprint registry items and the size of the sprint registry, deciding on specific commitments. Excel spreadsheet is often used to run the Backlog, but it is possible to use JIRA or Enterprise Architect.
During a sprint, it is the Scrum Master who updates the registry to show clearly the tasks performed, as well as the amount of time needed to complete the remaining work. The progress must be estimated daily, which often takes the form of a graphic, resulting in the so-called Sprint Burndown Chart.