Scrum compact – Part 5: agile practice
Timed Development: The Sprint Cycle
The work in the Scrum process is staggered, usually with a period of between 1 and 4 weeks. The associated fixed time period is called a sprint, cycle or iteration. In each time interval, a small piece of the overall project is processed and completed. The goal is to have a functioning (sub) product after each iteration (continuous delivery of results). The sprints provide the team with the opportunity to get early feedback from potential users and the product owner.
The kick-off meeting
A Scrum project starts with a kick-off meeting in which the project is discussed for the first time with the project team. Goals, customer expectations, and the product backlog are discussed.
Sprint Planning Meeting
The Sprint Planning Meeting marks the beginning of a sprint. This first meeting consists of 2 parts. In the first part, the team is committed to a set of features created in this sprint. In the second part of the meeting, the team collects the tasks that have to be done in order to deliver the agreed user stories. The sprint planning meeting lasts one to two hours per week development.
In the Daily Scrum, which typically takes place at the beginning of a working day, team members meet for a maximum of 15 minutes. Each presents what he has done since the last Daily Scrum, what he will do until the next Daily Scrum, and what has slowed him down. The aim of the meeting is to ananalize the work of the team members and, if necessary, to adapt the procedure. The analysis happens during the meeting; the adaptation can take place after the meeting. The team does not have to solve the problems during the meeting. All you have to do is address the difficulties and decide which team member will take care of it.
The Sprint Review marks the official end of the Sprint. All stakeholders are invited to this meeting. The team shows what it has achieved and demonstrates the stories that have been implemented. Stakeholders can now see how the product has progressively improved through this sprint. They can provide feedback to the team, allowing them to better analyze and customize the product. The Sprint Review should be between 30 and 60 minutes for each week the Sprint lasts. If the team did not succeed in implementing a user story, then this is the time to tell the stakeholders.
At the end of a sprint, the team has another meeting in addition to the sprint review: the retrospective. Scrum supports the idea of continuous improvement. The review that takes place at the end of each sprint is the time for the team to learn what was learned in the sprint and how to apply what they have learned to improve it. The review takes one to two hours for each week of development time. It is not the purpose of the review to make a long list of things that went well or wrong. Suffice it to find one or two things that will make the next spring more effective.
Shared Code Responsibility
In Scrum, the entire team is always responsible for the entire product and thus for the entire source code. This is to ensure that a consistent programming style is maintained and the team remains capable of acting in all areas of the code even when team members are exchanged.
With the help of continuous integration, it is intended to ensure that an incomplete, yet functional system is available virtually at any time. For this purpose, the implementation is divided so that each implementation increment leads to a functional increment for the entire system. The runnability of the system is checked every night, for example, by automated tests.
It has often been helpful in software development to first test a module before building the module yourself. This approach has several advantages: The tests formulate the acceptance criteria. Functionality can be clarified before investing in the implementation. It is prevented that the creation of tests for lack of time is waived. Tests are an essential means of quality assurance in Scrum.
Refactoring refers to the structural transformation of an existing code base in which the external behavior of the system does not change. The conversion takes place in a series of small steps, in the hope that not much can go wrong. Refactoring is used primarily to correct design deficiencies. Instead of thinking too much about designing a system in advance, it’s better to use refactoring to fix design errors later. Only with the help of automated tests can it be proven after a refactoring that the behavior is equivalent to that before refactoring.