The 9 Most Confusing Pairs of Scrum Terms Explained

We asked Reddit which Scrum terms teams misunderstand the most.

One telling response was: “All of it really.”

Scrum Masters and coaches often throw jargon at developers who lack formal training in Scrum or Agile. Little wonder they get confused about the difference between Agile and Scrum, or relative versus time-based estimation.

Such miscommunication leads to frustrations, mistakes, and even failed projects.

To collaborate effectively, you and your team need to be speaking the same language.

We’ve made a list of the nine most confusing pairs of terms to shed some light on why some terms are so often misunderstood and what the difference is between concepts that may look similar.

Agile is a philosophy – a set of values and principles – about improving software development. Scrum is a practical framework based on that philosophy that tells you how you can successfully execute software development projects.

The terms Scrum and Agile are used interchangeably even by people who practice Scrum, fueling the confusion. Agile is about the why and what of improving software development, Scrum is about the how.

Their foundational documents highlight this distinction:

The Agile Manifesto tells you to value “responding to change over following a plan.” The Scrum Guide explains how to achieve that by working in short sprints with customer feedback at the end of each cycle.

A framework and a methodology both tell you how to do something, but an agile framework leaves room for customization and interpretation. A methodology is rigid and tells you exactly how to do something.

If it were about cooking, a framework gives you the essential ingredients and lets you figure out how to cook them. In contrast, a methodology is an exact recipe telling you what ingredients to use, how to prepare them, and in which order.

Scrum is a framework because it gives teams a loose structure, but teams can still choose their own technical processes and development roles. Extreme Programming (XP) – another Agile approach to software development – is a methodology, because it outlines exact technical practices.

There’s an ongoing debate on where Agile falls on this spectrum – is it a mindset, philosophy, methodology, or something else entirely? Since Agile doesn’t contain steps on how to do anything, we refer to it as a philosophy or a set of guiding principles.

When teams self-organize, they only choose how to accomplish their work. When they self-manage, they also decide who does what and when.

For example, in a self-organized team, the leader of a team or someone outside the team might determine the list of tasks and set assignees and due dates. The team then gets to decide how to accomplish the task. A self-managed team picks tasks, assignees, and due dates.

Neither of these Scrum terms means team members can do whatever they want. There can still be authority and hierarchy within the team. As one respondent on Reddit put it:

The Scrum Guide used to refer to Scrum teams as self-organizing. Since last year it says self-managing instead, and this change caused some confusion. Generally speaking, teams led by a Scrum Master or Product Manager are self-organized, not self-managed.

The Product Backlog is an ordered – and ideally prioritized – list of all the ideas you could possibly work on to develop your product further. The Sprint Backlog only contains items you have selected from the Product Backlog to work on during the current sprint.

An important distinction is that you can continuously expand and refine the Product Backlog. In contrast, you shouldn’t change the Sprint Backlog once you start a sprint.

Because these Scrum terms are closely related, and people often refer to “the backlog” in their day-to-day work, it’s easy to get the two mixed up.

You use a relative estimation method when you scope your tasks with a metaphorical scale such as 1-10, story points, or the sizes of T-shirts or even with dogs or fruits! With time-based estimation, you approximate the time it will take to complete a task.

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

This inclination keeps teams estimating in time even though it’s challenging to know in advance how long a software development task will take, and it turns out humans are actually pretty bad at it.

You often need to assess based on incomplete information and unpredictable dependencies on other tasks and team members. Estimating complexity relative to another task is more manageable, even with incomplete information.

Confusion arises when team members give a “relative” estimation by doing a mental time calculation first, instead of genuinely considering a task’s complexity on a non-time-based scale.

One product increment holds all the tasks in one sprint. When you ship or launch an increment to external stakeholders and users, it’s a release.

In Scrum theory, teams aim to release small pieces of working software each sprint, so each sprint leads to a new product increment.

In reality, in most organizations, releases consist of several increments, especially when releases are part of larger projects. In such cases, the developer might be done coding and consider his work “released”. But if it’s not in the live product, it’s not a release.

Also, note that while infrequent releases to users aren’t agile, neither are the opposite: frequent releases without reflection and learning from customer feedback.

The definition of done specifies quality criteria for all your features and tasks. It operates at the macro level. Acceptance criteria apply on the micro-level – they define how to verify completion of a specific task.

The Scrum Guide officially defines the definition of done, and says that each product or sprint backlog needs one. Acceptance criteria don’t get mentioned, and not every task requires them.

Here is an example of each:

Because both these Scrum terms specify when something is completed and under what conditions, people often use the two interchangeably.

The Sprint Review concludes a sprint with an inspection of the completed work and a discussion between the Scrum team and stakeholders.

You can include a product demo in this review where teams show off what they’ve built in a sprint, but it shouldn’t be the only component.

At many organizations, the Sprint Review = a demo. The Scrum Guide advises explicitly against this:

There should be room to assess the impact of the sprint’s work on the overall progress toward the sprint goal and time for discussion and updating of the product backlog together with stakeholders.

Continuous integration means you integrate your code into the team’s codebase at least once per day. With continuous delivery, the updated codebase for the entire product gets released to end-users regularly – daily or several times per week – and often automatically.

These distinctions might just seem like technicalities, but they facilitate agile practices. When you integrate your code daily, you have to break down your work in small chunks and can’t procrastinate (at least not for more than half a day ). And when your team releases the updated codebase to users often, you enable quick feedback loops.

These Scrum terms are confusing because the wording and the underlying technical actions are similar. Plus, as we’ve seen a few times by now, even most practitioners can’t seem to agree on the distinction.

Shared language is essential to effective communication, and effective communication precedes successful collaboration.

Whether it’s writing documentation, participating in meetings, or just building trusting relationships, it all starts with a shared vocabulary.

So if your team are still calling the Daily Standup simply “the Scrum” or struggling talking at cross purposes, share this article with them. Or bookmark it to refer back to next time someone gets confused!