In the previous articles, we finished looking at the basic artifacts of the scrum. Let’s start dealing with processes – Scrum Sprint.
A stable and purposeful set of interrelated actions that transform inputs and outputs according to a specific technology.
The following processes exist in scrum
- Sprint
- Sprint planning
- Daily Scrum
- Sprint Review
- Retrospective
- Cancel Sprint
Sprint (Iterations)
Login: Backlog
Exit: Increment
– Includes communication with the customer, analysis, increment development, and testing.
– 1-4 weeks. All sprints are of equal duration.
– Team composition and requirements do not change during the sprint
A Scrum Sprint is a basic scrum production cycle.
Work on any project is broken down into sprint iterations. Each cycle includes all the production operations necessary to produce a result (analysis, development, quality control, etc.). During each Scrum Sprint , the top of the backlog is turned into an increment according to priorities, feedback is received, and then the next sprint begins.
In this way, the project is gradually approaching the desired results. Working in iterations allows you to refine or modify the requirements at any time. It means flexibility and quick reaction to changes in the market, business, and understanding of the customer. Changing requirements should not affect the stories that are being implemented in the current sprint. Changing requirements translates into creating or changing stories that are in the backlog. The next sprint selects the next stories from the top of the backlog and the cycle repeats. If the requirement for a story implemented in a sprint has changed so much that it makes no sense to continue with the current implementation, the product owner can remove the story from the sprint or replace it with another of the same labor intensity in agreement with the team. If the change involves a large number of stories, the product owner may cancel the sprint.
The length of sprints is determined in advance by the team. This is the result of a compromise, an agreement between the team and the product owner.
Usually, the product owner and the orderers like shorter sprints because they get a faster result that they can look at and adjust the “flight.” Short sprints cost less, so there is less risk of wasting money. With short sprints, you can change requirements faster and see those changes.
The team prefers longer sprints. In this case, there is a greater proportion of time allocated to increment creation. Less time is spent on the processes that accompany each sprint (demo, retrospective, etc.) A 1-week sprint would have to do this 4 times a month, while a monthly sprint would only have to do it once. There is no point in making a sprint shorter than a week because it is difficult to make a valuable increment of product in less time. A maximum of 4 weeks is a recommendation, just like everything else in the scrum. For example, at Nokia, where there is work not only on software but also on hardware, sprints of 6 weeks are accepted.
It is not customary to change the composition of the team during the sprint, because otherwise the responsibility of the team is diluted. The team that planned the sprint and made a commitment to its goal completes it and achieves the result. In practice, this recommendation is difficult to follow, especially in a multi-project environment where resources can be reallocated to a higher priority or “burning” project at any time. In such situations, you need to exercise common sense and compare: which of the solutions will bring more benefit and less damage.
A good practice is for the product owner to define a sprint goal. This brings the team together, helps with prioritization within the sprint, and at the end of the sprint allows you to understand not only whether it meets the readiness criterion, but whether it is successful.
