TOP-20 most important Scrum terms

To be on the same page with your colleagues,  novice testers who are just starting to work in IT can find some terms complicated in team conversation. And if everything is more or less clear with ordinary «dailies», then the story point and increment of the product can frighten you or at least make you cautious. To explain the general terminology of the Scrum methodology, we have prepared our top 20 most common terms.

Scrum terminology

It is important to understand and separate the concepts of Scrum and Agile, and it is actually easier than determining which came first – the egg or the chicken?

Agile is a family of flexible approaches to software development. These approaches are based on the manifesto of software development, the main points of which are as follows: «People and communications are much more important than process and tools», and «A functioning product is much more important than perfectly comprehensive documentation». «The willingness to improve the product is more important than sticking to the original plan».

Popular representatives of this approach are such methodologies as Scrum and Kanban.

The difference between the two is that Scrum has a more structured approach, where one team works on the project during a sprint (which can last from a week to a month on average), while Kanban is a more balanced approach that should ensure the work of various specialists within the team. However, to determine the difference between these two techniques, you can read the article that we already have on our blog.

To sum up, we can say that Scrum and Kanban emerged from Agile. And Agile is their manifesto and philosophy.

Let's start our top terms of the Scrum methodology with the roles in the team.

The development team is a team of developers who work on creating functionality. The team is a self-organized and cross-functional unit in the methodology, which means that the team itself reports on the progress of work on the project and chooses the order of tasks from the product backlog. It is important to understand that the interpretation of this term involves the work of specialists who are familiar with the specifics of the project and will work on product creation from start to finish.

As it has already been mentioned, the team consists of specialists from different areas, each of whom has their own view. There is no hierarchy, everyone in the team sets a task for themselves, having previously assessed their capabilities, but we should not forget that mutual assistance is an important component of teamwork because everyone is jointly responsible for the result of the work.

The Product Owner is a team member who is responsible for maximizing the value of the product developed by the scrum team. This person is responsible for effective backlog management and reflects customer needs.

Tasks of the product owner include:

• development and discussion of the product goal;
• creation and explanation of backlog items;
• arrangement of backlog elements;
• ensuring transparency, accessibility, and understanding of the backlog.

The Scrum master is a facilitator and a  trainer for the rest of the team. They help teams get their work done by removing any obstacles or barriers that get in the way of project activities. These professionals teach necessary  Scrum concepts to the team and coach team members in communication, ensuring successful Scrum events. However, the scrum master helps not only the team, but also the product owner to find techniques for effectively defining the purpose of the product and managing the backlog; apply experiential product planning in a complex environment, and mediate customer interactions as needed.

Types of events in the Scrum methodology

Iteration or sprint is a cycle of tasks or time segments that can range from one week to a month. During this period, the team should develop a ready-to-test product. A sprint consists of the following several statuses:

• planning (Sprint planning);
• inspection of work on the project (Daily Scrum);
• presentation of the result (Sprint Review);
• analysis (Sprint Retrospective).

Team specialists decide the number of tasks they can complete during one sprint.

And, of course, there are certain rules and features of sprints, such as:

• no changes occur during the sprint that could put the main goal of the sprint at risk;
• the quality does not change;
• the product backlog is refined as necessary;
• acquisition of new skills and information, scope, and execution of processes can be reviewed together with the product owner.

The fixed duration of the sprint is explained by the fact that sprints that are longer than one month often lose the relevance of the goal and complicate the work process or increase risks. A sprint can be canceled if the sprint goal has lost its relevance, but cancellation is possible to be done by the product owner only.

Sprint Planning is a stage of the sprint that initiates the sprint, during which the work that needs to be done is planned. Designation and formation of the sprint goal also take place at this stage. As a result, a plan created by the entire team appears. During planning, the following issues are considered:

• What is the value of this sprint?
• What will be ready in this sprint?
• How will this work be done?

Daily Scrum is a daily meeting of the scrum team to simplify the process of working on the project. To make it comfortable, meetings always take place at the same time. Such meetings improve team communication and eliminate the need for frequent calls to resolve work-related issues. Sometimes the product owner and the scrum master can be present at such meetings.

A Sprint Review is a review of the result achieved during the sprint. The team presents results and discusses progress toward the product goal. During this, the team also analyzes the next steps, which is why the backlog may be slightly modified taking into account new opportunities. It should be understood that the sprint review is not a presentation, but a working session. In time, this session will be limited to four hours for a sprint that lasts 1 month.

Sprint Retrospective is a general meeting to determine the results of the sprint. The main purpose of the sprint retrospective is to plan for improving the quality and efficiency of the next sprint. Meetings are initiated by the scrum master, so he, like the team, analyzes not only the features of the project that appeared during the last sprint but also the communicative component of the team's work.

A retrospective concludes a sprint and can last as little as three hours for a month-long sprint.

Getting to the topic of artifacts of the scrum methodology, first, it is worth mentioning that it is the artifacts that reflect work and value. Artifacts are designed to maximize the transparency of key information, so those who inspect them will have the same basis for adaptation. 

Here are three essential artifacts:

• Product backlog;
• Sprint backlog;
• Product Increment.

We'll provide the explanations for each of the artifacts, and let’s start with the product backlog.

Product backlog is an organized list of what is needed to improve the product. It is the single source of work done by the scrum team. This list is constantly updated.

Items on this list can be implemented by the team to a state of readiness during the sprint and are considered ready for transfer to the sprint already during sprint planning. In the process of sprint planning, all the points related to the task completion are clarified. Refining backlog tasks can be the process of breaking a large task into smaller tasks that can be completed during sprints.

Sprint backlog is a work scope plan created by developers for themselves. It is both an accessible and visual picture of the work that must be done during the sprint in order to achieve the sprint goal (Sprint Goal). The goal of a sprint (Sprint goal) is a single, cumulative goal for the entire sprint.

The product increment is an addition to all of the above. An increment is all the backlog items with the status «done» (Done), which can be viewed by the customer himself during the sprint review. Of course, the increment can be sent to the client even before the end of the sprint.

A Done status ensures that there are no misunderstandings about when a sprint or task can be called «done». Scrum team members must clearly set the requirements for what needs to be done so that both the customer and the team understand and agree.

Timebox is a certain period of time that was agreed in advance. This time cannot be extended under any circumstances. The goal is to keep events within time frames as short as possible, but still as long as necessary. For example, a daily Scrum should not last more than 15 minutes. Timeboxing in this event makes it a habit for the team to stick to the 15-minute limit so as not to get distracted.

Covering the terminology of processes during a sprint, it is worth paying attention to terms related to processes.

Burndown Сhart is a scale that is used to see the amount of work left in the sprint. Typically, the amount of work remaining in a sprint is plotted against the number of workdays. The bar should go down after each working day, which is why it is called a burndown chart.

Burn-up Chart is a scale that shows the cumulative amount of work done, plotted on a chart of working days. Each time a new item is considered as Status Done, the bar on the chart rises.

The difference between the Burndown Chart and the Burn-up Chart is that the former (Burn-down chart) indicates the number of tasks left for the team, while the Burn-up chart indicates how many of the team's tasks have already been completed.

Ideal hours/days is a concept used to determine the working capacity of the Scrum team. For example, an 8-hour working day is considered normal working time. However, some of these hours are used for planning, meetings, unscheduled work, or social interactions and may not be considered «product/service development hours». It is more reasonable to expect team members to start working 6 of the 8 hours available on a product or service.

Release planning is an approach to work organization that takes into account the flexibility of the system support development process. Its main purpose is to control regular interim releases as well, as opposed to the traditional approach where everything is focused mostly on big major releases. Release planning occurs after defining the main purpose of the product, its appearance, and the development process.

A story point is a tool for assessing the complexity and time required for a team to complete a certain task. Assigning tasks based on relative difficulty allows you to more accurately reflect the effort expected to complete the task because, unlike time estimates, old points only apply to the current task and not to unexpected emails, meetings, or delays that may affect the task's time. Fibonacci numbers are usually used for story points. Story Points are used during Scrum Poker and you can read more about it in another article on our blog.

User Story is a short statement of the intentions of the user of the product and what this product should do for the user. In other words, it is a tool that helps to capture the description of the product's actions from the user's point of view. In addition to focusing on the user and setting the dynamic, user stories also provide a brief but accurate description of what the customer expects to experience during the product iteration. More details about User Story in our article.

Velocity is a measure of the amount of work a team can complete during a single sprint. It is thanks to speed that you can determine how many items from the backlog can be completed by the team in one sprint.

In this article, we have collected for you the most important terms of the Sсrum methodology and we hope that it was useful.