What is Scrum?
Scrum is a technique that helps teams work together. With the help of which the team of employees of the company must learn from the experience gained, master the principles of self-organization, working to solve the problem, and analyze their successes and failures to constantly improve.
Scrum is most used by application development teams, but its principles and experience can be applied to all kinds of teamwork. This is one of the reasons for the popularity of the technique. Scrum is often presented as an Agile project management platform. Scrum team members hold meetings, use dedicated tools, and take on specific roles to organize and manage work.В этой статье мы рассмотрим, из чего состоит традиционная методика Scrum. В этом нам поможет руководство по Scrum.
Sprints
A sprint is a short time frame during which a scrum team does a given amount of work. Sprints are at the core of scrum and agile methodologies and choosing the right sprints will help your agile team deliver better software without unnecessary headaches.
With scrum, a product is developed in a series of fixed-duration iterations called sprints, which break down large, complex projects into small tasks.
With scrum, a product is developed in a series of fixed-duration iterations called sprints, which break down large, complex projects into small tasks.
Many people associate Scrum sprints with Agile software development so often that Scrum and Agile are mistaken for synonyms. However, it is not. Agile is a set of principles, and Scrum is a methodology for actively solving problems.
The many similarities between global agile tasks and scrum processes, quite rightly, lead to the two concepts being associated with each other. With sprints, teams can follow the agile principle of “delivering working software frequently,” as well as the agile challenge of “responding to change as planned.” Scrum attitudes - transparency, validation, and adaptation - complement the agile methodology and play a central role in the concept of sprints.
Scrum sprint planning and execution
The Scrum authors really did it all. To schedule an upcoming sprint, you need to have a sprint planning meeting. Sprint planning is an exercise where the team collectively answers two basic questions: What work can be done in this sprint, and how will it be done?
It is the responsibility of the Product Owner, Scrum Master, and Development Team to select the appropriate work items for the sprint. The Product Owner defines the Sprint Goal and the tasks from the Product Backlog that will accomplish this goal.
The team then creates a plan for the backlog tasks to be completed by the end of the sprint. The selected work items and the plan for completing them are called the sprint backlog. By the end of the sprint planning meeting, the team is ready to get started. To do this, you just need to select tasks from the sprint backlog and change their status from "In Progress" to "Done" as the work is completed.
During the sprint, the team gathers for daily Scrum meetings (stand-ups) to discuss the progress of the work. These meetings are needed to identify blockers and issues that may affect the achievement of the sprint goal.
At the end of the sprint, the team shows the work done in the sprint summary. Here you can showcase the results of your work to stakeholders and other team members before they get into the work environment.
End the sprint cycle at my favorite meeting, the sprint retrospective. This is where the team can identify areas for improvement in the next sprint. With this information, you can begin the next sprint cycle. Forward!
Product backlog
The Product Backlog is a list of work items, arranged in order of importance, for the development team. It is drawn up based on the roadmap and the requirements in it. The most important tasks are located at the beginning of the product backlog so that the team understands what work should be done first. The speed at which a team completes backlog tasks does not depend on the wishes of the product owner, and he, in turn, does not put pressure on the team. In contrast, the development team independently selects tasks from the product backlog when they have the necessary resources, performing them continuously (Kanban) or iteratively (Scrum).
Do's and Don'ts
Even if the basics are already known, most teams stumble upon getting started with sprints.
What do we have to do:
-
Make sure the team understands the purpose of the sprint and how to measure success. It is important for all participants to tune in and move towards a common goal.
-
Make sure you have a clear and understandable backlog with priorities and dependencies. If the backlog is not properly maintained, it can become a big problem and disrupt the workflow.
-
Make sure you gauge team speed correctly and consider events such as vacations and general meetings.
-
Use the Sprint Planning Meeting to expand your current task description with more details. Encourage team members to outline a general outline for all the stories, bugs, and issues that go into the sprint.
-
Discard tasks that make your team unable to resolve dependency issues. Such tasks include the work of the other team, design and legal confirmation.
-
Finally, after deciding or planning, make sure there is someone who captures this information in a project management or collaboration tool like Jira claims. In this case, later everyone can quickly read about the decision and its rationale.
And if you are already working to become a strong scrum expert by following the guidelines, then also check out the DON'T DOES.
What not to do
Don't take too many stories, don't overestimate the speed of work, and don't set tasks that can't be completed in this sprint. You don't want to let yourself or your team down, do you?
Don't forget about quality and technical debt. Make sure you have time to do quality control and non-feature work, such as bug fixes and development controls.
Avoid situations where the team does not have a clear understanding of the content of the sprint. Determine the scope of work and do not get hung up on the speed of execution; make sure all team members are working in the same direction.
Also, don't take on too much uncertain or risky work. Share large stories or stories with a high degree of uncertainty and feel free to leave some of the work for the next sprint.
If the team expresses concerns about speed, the level of uncertainty in the work, or too much volume, do not ignore the opinions of the participants. Consider this issue and adjust as needed.
Sprint planning
Sprint planning is an event in scrum that marks the start of a sprint. Planning determines the amount of work for the sprint and how that work will be done. Sprint planning is done with the assistance of the entire scrum team.
In Scrum, a sprint is a fixed amount of time in which all work is done. But before taking action, the sprint needs to be planned. It is necessary to determine the duration and purpose of the sprint, as well as the starting point of the work. At the sprint planning meeting, the range of main tasks and the vector of the sprint development are determined. If the meeting is handled correctly, the team leaves the meeting motivated, charged with ambitious goals, and focused on success. Poor sprint plans can lead a team to a standstill if unrealistic expectations are presented.
-
"What". The Product Owner sets out the main objective (or goal) of the sprint and explains what tasks from the backlog need to be completed to achieve this goal. The scrum team decides what to accomplish in the upcoming sprint and what needs to be done during the sprint.
-
"How". The development team draws up a plan of work to be completed to achieve the sprint goal. The final sprint plan is agreed between the development team and the product owner in terms of value created and effort expended.
-
"Who". Sprint planning is impossible without the involvement of the product owner and the development team. The product owner sets a goal that depends on the desired value. The development team needs to understand if it can achieve this goal (and how to do it). If one of these parties is absent from the event, it becomes almost impossible to plan a sprint.
-
Input data. The Product Backlog is a great starting point for sprint planning, as much of it can be incorporated into the current sprint. The team should also analyze the current work that it is doing in the increment and evaluate its own capabilities.
-
Results. The most important thing a team can leave a sprint planning meeting with is understanding what needs to be achieved in the sprint and how to start moving towards that goal. This can be illustrated using the Sprint Backlog.
Preparing for a Sprint Planning Meeting
For a sprint planning meeting to be successful, a certain amount of organization is required. The Product Owner should be prepared to revisit the lessons learned from the previous Sprint Review and learn from stakeholders and their product concept. We can say that they set the stage for the sprint. To make the current situation transparent and understandable, the product backlog should be brought in line with modern realities and adjusted. A separate Scrum event is dedicated to refining the backlog; some backlogs do not need it, so it is not necessary to run it. However, most teams should get together before planning a sprint to review and adjust the backlog.
Time Limit for Sprint Planning
Sprint planning should take no more than two hours per sprint week. For example, a two-week sprint planning meeting should not last more than two hours. In this case, you limit the maximum amount of time a team can spend planning a sprint. The Scrum Master is responsible for ensuring that everyone in the meeting understands the time constraints. If the team gets the job done early, the meeting ends. Limits only define the maximum duration of a meeting; no minimum duration is specified.
Sprint Summary Reviews
To cross the finish line and finish the job, you need to make a good plan, define criteria for work readiness, and then work methodically. A lot of this is about sprint planning, but teams need more than a plan to successfully review the outcome of the sprint and the sprint itself. They should clearly articulate the approach to work and the criteria for readiness.
Well-defined readiness criteria help teams focus on the ultimate goal for each work task. When the Product Owner adds work to the team backlog, it is their responsibility to define the acceptance criteria. What should be the completed user story? At Atlassian, the Jira team writes the acceptance criteria and test notes in the same place as the Jira user story description. This gives all team members a complete picture of the progress of each task. What are Acceptance Criteria and Test Notes?
-
Acceptance criteria are metrics by which a product owner can determine whether a user story deliverable meets their requirements.
-
Test notes are short, focused instructions from the QA team that a developer can follow to write better functional code and automated tests.
When objectives are clearly defined, anyone can get their job done successfully. You can easily add additional fields to Jira. To do this, the administrator only needs to click the admin button on the task.
A little tip in the end
Teams who are new to sprint summary reviews have a strong temptation to combine summary review with retrospective. The Sprint Outcome Review meeting is not associated with a Sprint Retrospective. Take time to enjoy the results of your labors. Celebrate victories with courage. Good reviews of sprint outcomes build team morale and motivate them to do more.