The most complex Scrum terms and their explanations

Previously, we reviewed the basic terminology of Scrum software development methodology. However, the topic is not fully covered, so we have prepared the second part of the article, where you will learn about the peculiarities of some complex Scrum terms that are often a stumbling block for testers. 

Why is it important to understand the nuances of the methodology's terminology (The «scrum master» term alone will probably sound quite odd)? A detailed and accurate knowledge of the terms will provide a better understanding of the ongoing processes. And for the most curious, it will answer the question «Why is it so?».

The concept of Scrum.

1. Agile is not just Scrum, but Scrum is definitely Agile 

Repetition is the mother of skill, so let's go back to the basic terms. Even though it may sound complicated and confusing, we need to clarify the difference between these two terms. 

So to explain the difference between them, the easiest way is to look at the official documentation:

• Agile is based on a manifesto. It is the manifesto that emphasizes the importance of changes in the project over strict adherence to the previous plan;
• The Scrum method is based on guiding principles. 

2. Is Agile a framework or a methodology?

Yes, there is a difference between these two terms as well. Although a framework is a set of structures and principles for achieving a goal (just like a methodology), at the same time it leaves «room for thought». And the methodology explains the whole process down to the details, especially the organizational part. The easiest way to explain this metaphor is through cooking. For example, the framework will be a list of products that we need for a stew. And the methodology will be an exact recipe with a tutorial on how to cut the products and cook them step by step. 

That is why Scrum will be a framework because it provides a simplified structure without step-by-step instructions where the team can implement its own technical processes and development roles. For example, an Agile approach such as Extreme Programming (XP) will already be a methodology as it includes precise technical techniques.

3. Are self-managed and self-organized teams the same thing?

A team is probably the most important unit in software development, so it's important to understand how it works. Both terms – «self-managed» and «self-organized» – are sometimes a stumbling block. 

Therefore, it is important to remember that a self-organized team will independently choose the way and method of completing a certain list of tasks, while a self-managed team will assign tasks to a specific team member and determine the deadline for completing this task. 

However, both self-managed and self-organized teams cannot do whatever they want. Both teams have to follow hierarchy and subordination.

For example, in a self-organized team, the team leader or someone outside the team can define a list of tasks and assign performers, together with deadlines. Then, the team decides how to complete the tasks. A self-managed team chooses its own tasks, goals, and deadlines.

The Scrum methodology instruction that we mentioned above used to define teams as self-organized. Since last year, the «self-managed team» term has been used instead, and this change has caused some confusion. Nevertheless, teams led by a Scrum Master or Product Manager are self-organized, not self-managed.

4. Product Backlog and Sprint Backlog

These similar terms make it easy to get confused or lose track of what they mean. However, the difference between them is very noticeable:

• product backlog is an organized and, in the ideal case, prioritized list of all the tasks you need to work on for the further development of the product; 
• sprint backlog contains only items selected from the product backlog to work with during the sprint.

An important difference is that it is possible to constantly expand and improve the product backlog. However, in the case of a sprint backlog, testers must not change it after the start of the sprint.  

5. Relative and time-based estimation

The relative estimation method is used where tasks are defined using a metaphorical scale, such as 1 to 10 story points, T-shirt sizes, or even dogs or fruits. Time-based estimation is used to estimate the time required to complete a task.

Time-based estimation comes naturally to most people, since we constantly estimate things in absolute terms – how much something might cost, weigh, or how long it takes to get from point A to point B.

This tendency helps teams estimate time, despite the difficulty of determining in advance how long a software development task will take. As it turns out, people are actually not very good at this.

Often, it is necessary to estimate based on missing information and unpredictable dependencies on other tasks and team members. The complexity estimate relative to another task is more manageable, even with missing information.

Confusion occurs when team members give a «relative» estimate: first estimating the time, instead of actually considering the complexity of the task on a non-timeline.

6. Product increment or Release?

A product increment contains all the tasks in one sprint. The moment an increment is sent or launched to external parties and users, it is a release.

According to the Scrum theory, teams focus on releasing small pieces of working software each sprint, so each sprint leads to the growth of a new product. 

Actually, in most organizations, releases have several steps, especially when they are part of larger projects. In such cases, a developer might finish coding and consider their product «ready for release». However, if it's not in the actual product, it's not a release. 

7. The «Done» definition and acceptance criteria

The «Done» definition defines the quality criteria for all your functions and tasks. It works at the macro level.

Acceptance criteria are applied at the microlevel –- they define how to check the completion of a specific task.

The Scrum Guide officially uses the term «Done» and states that every product or sprint backlog needs one. Acceptance criteria are not mentioned, and not every task requires them.

Here is an example of each:

• The «Done» definition: the test is passed, the quality assurance is completed, and the acceptance criteria for each element are met;
• Acceptance criteria: when the user clicks the «change password» link, the application displays an error message in case the user is not registered with an email address.

As both of these Scrum terms indicate when something is completed and the conditions under which it is completed, they are often used interchangeably.

8. Sprint Review and Sprint Demo

The Sprint Review finishes the sprint with a review of the completed work and a discussion between the Scrum team and interested parties.

It is possible to include a product demo in this review, in which teams present what they have created in the sprint, but it should not be the only component.

In many organizations, the sprint review is defined in the same way as the demonstration. The Scrum Guide strongly disapproves of this:  

«The sprint review is a working session, and the Scrum team shouldn't just limit itself to the presentation».

There should be time to assess the impact of the sprint's work on overall progress in achieving the sprint goal and to discuss and update the product backlog with interested parties.

9. Continuous integration and continuous delivery

These two terms may sound very similar, but they both have nuances. Continuous integration means that your code is integrated into the team's code base at least once a day. In continuous delivery, an updated code base for the entire product is provided to end users on a regular basis – daily or several times a week – and often automatically.

Continuous integration or continuous delivery?

These distinctions may only seem like technical difficulties, but they facilitate agile practices. When you integrate your code daily, you can't delay (at least not for more than half a day) and must break your work into small parts. And when your team frequently releases an updated codebase to users, you enable fast feedback loops.

These Scrum terms are confusing because the formulation and basic technical activities are similar. Moreover, as we have seen several times, even the majority of testers cannot agree on the difference.

In this article, we've covered the most common terms of the Scrum methodology, which often become a stumbling block for beginners and others. In some cases, all the terms can be reviewed and understood without ambiguity, but some require more attention and a broader view, which is exactly what helps to develop the skills of a good tester.