Processes in Scrum

Sprint planning

Sprint planning is the initial stage in the Scrum sprint. It determines the scope and ways of doing work during the sprint. The entire Scrum team is involved in planning.

A sprint is a clearly defined period of time during which a specified piece of work must be completed. A sprint needs planning before it starts. First of all, you need to determine the duration and goal of the sprint.

At the planning workshop, the list of tasks and the goal of the sprint are agreed. It is important to charge the team with the right motivation to work, so that each member is focused on success.

If the sprint is poorly planned, then this can lead the team to failure. Developers will not be able to cope with the expectations placed on them, because the tasks turned out to be unrealistic.

Questions to consider when planning a sprint:

• The customer or software owner announces the goal of the sprint, along the way explaining how to achieve it. The Scrum team finds out what tasks can be completed in a future sprint to achieve this goal.
• Developers distribute a work plan among themselves, which is agreed with the software customer.
• The customer (owner) of the product always takes part in drawing up the sprint plan. He sets a goal, and the programming team must find out if it can be achieved in a sprint.
• The plan should use a product backlog, information from which can be added to the plan.
• Team members should end the planning meeting with a clear understanding of what they need to achieve the result. You can display the order of future actions in the sprint backlog.

Planning should not exceed two hours per week. The Scrum Master must explain to everyone that there are time limits. If all work issues are resolved quickly, then the meeting can end earlier than usual. There is no minimum duration for such a meeting.

Task evaluation

Assessing the complexity of the work does not need to overdo it. The planning process needs not an exact, but at least an approximate assessment of the complexity of the development. The team must not only understand the goal of the sprint, but also compare the goal with the capabilities of their team.

To assess the complexity, you can use the usual clothing sizes for everyone (L, XL, XXL). Of course, this does not give a guarantee of accuracy, but still.

In order for the assessment of complexity to be more accurate, mutual understanding is needed. Team members should openly share their opinions and not be afraid to ask questions of the product owner.

Criticism towards the team after the work is completed can lead to the fact that when planning the next sprint, the forecasts will be less optimistic. This will help the team avoid repeating the mistake and protect it from being negatively assessed in the future.

Evaluation of difficulty in points, points and hours

Typically, development teams estimate the complexity of their work over time. But some Agile teams choose to rate difficulty in points or points. This is a better indication of the total cost required to implement a backlog item or other assigned task.

Points are awarded based on the complexity and volume of work. In addition, possible risks are taken into account. Scoring using this method helps to effectively break down the work into small steps.

By regularly using the scoring method (points) when planning, teams have a better and more accurate understanding of how much time they will need to complete the work. In addition, there are other advantages as well.

• The time estimate does not take into account work that is not directly related to the project, although it will certainly appear. Discussing work issues through a messenger, holding meetings - all this also takes time for team members.
• Emotions can influence the choice of dates. Scoring when evaluating work eliminates this factor.
• The assessment of the complexity of the work and, accordingly, the speed of completing tasks may be different for each of the teams. Work with points made cannot be considered as any indicator of speed. That is, there is no psychological pressure on the team.
• By correctly distributing labor costs and complexity, you can quickly and without conflict divide points for the work performed between the participants.
• The number of points received for completing a task depends on its complexity, and not on the time spent. Therefore, programmers will think about improving their efficiency, and not about how long it will take.

The disadvantage of complexity estimation is that it is often misused. For example, this method cannot be used to evaluate employees.

Teams should use a scoring system to better understand the amount of work assigned to them and prioritize correctly.

Daily Scrum Meeting

Workshops are important: at them, team members share their opinions, communicate and agree on further actions. Daily scrum meetings are also needed to raise team spirit and announce current news.

Stand-up is a brief meeting of the key project participants: the software owner, programmers and scrum master. The structure of the stand-up consists of three questions.

• What were we able to do yesterday?
• What are we working on today?
• What prevents us from achieving results?

Asking these questions stimulates development and helps identify problems within the team. When each participant communicates how he/she helps to achieve a common goal, this improves mutual understanding within the team.

It is important to remember that there is no single template for how to conduct stand-ups. Each team holds meetings according to its own model, based on the characteristics of the team.

And now let's discuss what is needed for the perfect stand-up and get acquainted with examples of effective stand-ups.

First you need to choose a time that suits everyone. Usually stand-ups for teams from the same office are held at the beginning of the working day - between 9 and 10 in the morning. This gives you time to better plan your schedule for the day. If team members work in different regions, then a time is chosen that suits everyone. For example, if some team members live in California and Sydney, then stand-up starts at 15:30 California time. Of course, stand-up after dinner is not convenient for everyone, but it makes it possible to keep in touch with colleagues on the other side of the ocean.

Keep track of stand-up productivity. Do not hold the meeting for too long - the concentration of attention should remain at its best. If possible, hold stand-ups no longer than 15 minutes.

Use the ball. It can be thrown to each other in turn. So everyone will be involved in the discussion. This game helps to keep the attention in the group. Use team retrospective. Stand-ups are used in many Agile methodologies, this does not prevent us from discussing the effectiveness of stand-ups at retrospectives. Someone meets every day, other teams - a couple of times a week. If it's hard for the team to benefit from stand-up, find the reasons for this and change something.

Sprint review

Spring review is carried out at the final stage of the sprint. It is necessary to check the product increment and tailor the backlog. The entire scrum team and all stakeholders participate in the review of the sprint results. The meeting is held in a relaxed format to improve the interaction of project participants.

The Sprint Results Review includes the following elements:

• The software owner shows what from the backlog has been completed and what has not.
• The programmers discuss what went well, where the difficulties appeared, and how they were eliminated.
• The development team shows the results of their work during the sprint, and what product increment they received.
• The Product Owner shares his thoughts on the current backlog. It also gives a forecast for the next goal and the deadline for its implementation.
• Everyone discusses what is best to do next based on market assessment and user interests.
• There is an exchange of views on the timing, budget and prospects for adding to the backlog.

The result is an updated backlog with new goals for subsequent sprints. The backlog can be changed if the situation requires it.

Sprint Retrospective

The Sprint Retrospective is a workshop that discusses how to improve your workflow. It also creates an improvement plan for the next sprint. The meeting usually takes place after the sprint review and takes no more than three hours. Leading the meeting is the Scrum Master.

The main goals of the Sprint Retrospective include:

• Sprint analysis (work of participants, results and problems).
• Discuss possible solutions to improve the workflow in subsequent sprints.
• Creation of a plan for the implementation of improvements by team members during the implementation of the project.

The Scrum Master invites team members to make suggestions on how to improve development efficiency. The team discusses the proposals and suggests certain ways and techniques for their implementation.

At the end of the Sprint Retrospective, the team should highlight a few improvement suggestions to implement in the next sprint. Suggestions can be implemented at any time, but Sprint Retrospective provides an opportunity to take a deeper look at their possible adaptation from the team's point of view.

This is where we end our discussion of the Scrum methodology. You can learn more about it in the thematic documentation or at your first workplace.