Resolved vs closed: What’s the difference?

This post was originally published on September 27, 2017, and updated most recently on March 3, 2021.

In task management, marking issues as resolved and closed is common practice. While these terms may seem similar, they represent distinct steps in a workflow, and their application varies. In fact, each team you work on could use them in slightly different ways.

To help clarify, let’s explore the range of definitions applied to resolved and closed statuses.

Why use resolved and closed?

To outsiders, these statuses may seem confusing — resolved sounds like a task is complete, so what else could possibly need to happen before it’s closed? Teams use these terms to communicate important nuances in a team’s workflow. While the task or issue at hand may be complete, it may also need to be verified or approved before it can be closed.

Together, these terms serve as the solution and verification of an issue. While your team can decide not to use these specific terms, you’re likely following the processes they represent regardless.

What closed and resolved typically mean

The most common definitions of resolved and closed status are given by developers:

• Resolved means a developer fixed an issue they were assigned.
• Closed means that the Quality Assurance Manager or appropriate team member confirmed the fix was done correctly.

Simple enough, right? A closed status confirms that a resolved issue was completed and verified. For many teams, this is the distinction they adopt. However, many adjust the terms uses to their workflow.

Teams often base their uses for these statuses on their work demands rather than these commonly understood definitions. For example, some teams opt to exclude the QA check from their process. Instead, they rely on the developer’s work as the last quality assurance check. For others, resolved could serve as a testing stage, leaving closed for live testing or launch. In some instances, teams choose to redefine the terms even further.

What resolved and closed can also mean

Outside of the development realm, resolved and closed take on entirely different meanings. For example, a marketing team might use these statuses to represent their editing process instead. While similar to the developer team’s usage, resolved would indicate that a project is complete but still open for editing. Meanwhile, once marked closed, work has been published or handed off to another team, preventing any additional edits.

Other useful statuses

Some teams choose to use different terms or work better with custom statuses for their tasks. Using our own project management tool, Backlog, you can create and add as many custom statuses as your team needs. Typical words and phrases that teams will add, depending on their departmental needs, include:

• Completed
• Done
• Fixed
• In review
• Urgent
• Pending changes
• Waiting approval
• A/B Testing
• Approved

In short, depending on your team and their needs for updates, as long as you ensure that your team understands each status and how it is used, there shouldn’t be any problems. It might even be helpful to create a document to add to a Wiki with a specific definition of each status and where they sit in the workflow.

Otherwise, these flexible terms become a hurdle for a team’s workflow.

The trouble with flexible terms

Flexible terms like resolved and closed present a series of obstacles for unprepared teams. Without a clear delineation of their definitions, team members won’t be on the same page. In turn, this causes one of two scenarios:

• The employee uses their best guess or best knowledge and misuses the terms.
• The employee does their best to not use these steps at all, nullifying their effectiveness.

Either option has the potential for derailing your team’s workflow.

Regardless of what you choose, clearly define each status and how they fit into your team’s workflow at a project’s start. Ensure that each member understands what your statuses mean and what stage they represent. Doing so will save your team time and reduce quality assurance errors in the process.

Final thoughts

Consider the team when determining which status terms to use and their meanings. Experienced teams should pivot from one definition to another with ease, but less experienced teams or individuals may struggle. In some cases, a Project Manager can reduce issues with new teams by having their preferred terms already in place.

Whether using resolved and closed or another set of statuses, decide early. Determine what definitions work best, and do your best to adhere to them. Mistakes happen, but with a clear process, these issues can be resolved and closed with ease.