I'm confused about the use of Artifact, Deliverable and Increment in a software project using Scrum. We use JIRA to create tickets. Let's say we have the following under an epic:

  1. Create a registration page
  2. Create a login page

In my understanding, the two tickets are the artifacts and they become increments when they are completed. Is that correct? If yes, then what is a deliverable here? Is it another word for increment?

Please help me understand this with some examples.

  • This is an example of what happens when you let a tool drive your process. Jira tickets are neither deliverables in a tangible sense, nor are they artifacts in the Scrum sense. You therefore have dictionary definitions, framework definitions, tool definitions, and your own company culture to deal with here. If you can at least acknowledge that Jira is a tool and not a framework or process I can give you a more pragmatic answer for your particular use case that doesn't conflate those things.
    – Todd A. Jacobs
    Jan 9 at 23:41
  • @ToddA.Jacobs I agree with you. And the tool is also not going to drive the process. It was an example and I wanted to get an understanding in the context of that. Thank you
    – sukesh
    Jan 10 at 5:40
  • For the regulars: "Jira" used to be called "JIRA" in all caps by Atlassian. We probably ought to fix the tag at some point as I don't consider it the same sort of foundational error like SCRUM vs. Scrum, but it still cries out for some consistency.
    – Todd A. Jacobs
    Jan 11 at 0:31

2 Answers 2



While artifacts, deliverables, and increments are all general terms, as well as terms of art within project management, two of them have specific meanings as part of the Scrum framework but "deliverables" does not. I'll focus on how Scrum defines these things, and that should enable you to work out your own mappings from Scrum to Jira even when there's no direct correlation.

For practical purposes, though, you should probably consider a Scrum Increment is the closest thing to a traditional deliverable even though it's an inexact match. You could also consider mapping current or future Product Goals as "deliverables," since each Product Goal is a product-related target that can be used in release planning.

NB: "Release planning" isn't a formally-defined element of the Scrum framework either. However, see "How to Perform Agile Release Planning" (Jacobs, 2015) for how to do so within Scrum and other agile frameworks.

Scrum Artifacts

"Artifacts" in general business usage are basically just relics or by-products of a process. See Merriam-Webster for a dictionary definition if you prefer.

However, the Scrum framework explicitly defines three artifacts:

  1. Product Backlog
  2. Sprint Backlog
  3. Increment

While a project may in fact create more than three artifacts, these are the only ones required by Scrum. Your backlogs are probably stored in Jira, so that may be one way to map your organization's notion of Scrum artifacts. Other things provided by Jira such as dashboards, reports, and so on could also be considered "artifacts" in the business sense but are not Scrum artifacts.

Scrum Increments

Generically, an increment is basically a progressive step towards something. In Scrum, an Increment is a reserved term specifically defined as "a concrete stepping stone toward the [current] Product Goal."

Scrum requires that you have only one Product Goal at a time, so for framework purposes the Increment must relate to progress towards that Product Goal. Furthermore, to have value "the Increment must be usable."

As an additional refinement, also note that the 2020 Scrum Guide says:

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

While it's unfortunate that you have to cross-reference such things yourself within the Scrum Guide, all the different pieces of the definition work together to define what an Increment is within the framework.

Jira doesn't really have a direct correlation to a Scrum Product Goal. While you could hijack epics, features, labels, components, or other aspects of the tool, there's no real 1:1 mapping of this concept within Jira itself.


A business deliverable is generally used as a noun but with the intended meaning of the intransitive verb:

to produce the promised, desired, or expected results

Despite being a tautology, deliverables are simply the things that are (or are expected to be) delivered. Scrum doesn't use the much-abused term "deliverable," but does in fact provide for specific commitments to be met:

  1. The Product Goal
  2. The Sprint Goal
  3. The Increment(s)

While you could potentially map an Increment to something baked into Jira, Product and Sprint Goals don't intrinsically map to any default elements of Jira so you will have to map them yourself.

For example, a Product Goal isn't a feature or epic, and it's not a Definition of Done. It's just "a future state of the product which can serve as a target for the Scrum Team to plan against." So, you might decide to leverage a pair of labels like "Product Goal" and "electrocutes customers on contact" to mark something in Jira as that future state you're targeting.

Likewise, each Sprint Goal is a "single objective for the Sprint...[that] creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives." This is exactly the opposite of how Jira encourages teams to work, so how you decide to map whole-team collaboration onto Jira rather than incorrectly focusing on "completing all the tickets" is a good inspect-and-adapt question for the team. Since you get what you measure, any ticketing system that assigns work to individuals instead of whole teams will work against this core Scrum principle.

So Which Scrum Commitment Most Aligns with "Deliverables?"

Given the foregoing, and drawing on a wider variety of material by Jeff Sutherland, you should probably consider Increments to be the closest analogue of business deliverables. Any Increment that meets the Definition of Done is a potentially releasable unit of value, and can be released at any time.

NB: This is a common use case for feature toggles, which allow a change to be released when ready without necessarily changing the form or function of the existing product at the time of release. This is also a form of continuous delivery, a topic that is broader than (but not orthogonal to, or required by) the Scrum framework.

Down the Rabbit Hole: Defining "Value"

Note that "value" isn't a defined or necessary attribute of a deliverable. A deliverable is really just an obligation to produce something or to hand something over. From a purely definitional perspective, a contractually-defined deliverable for a software project could be to deliver a pound of physical rocks; the only intrinsic value of handing over a bag of rocks as part of such a project would be adherence to the contract or statement of work.

In Scrum, an Increment that meets the Definition of Done can be (but does not have to be) released at any time. You don't have to wait until the end of the Sprint or the Sprint Review event to do so.

[A]n Increment may be delivered to stakeholders prior to the end of the Sprint. The Sprint Review should never be considered a gate to releasing value.

Even in Scrum, though, value need not be directly valuable to the end customer. The Scrum Guide leaves the definition of value largely to the Product Owner:

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

Pragmatically speaking, a Product Backlog item or Increment can also be valuable to the project (e.g. a tool chain upgrade that improves the product development process) or otherwise provides value by enabling the current Sprint Goal.

About the Ticketing Paradigm in Agile Frameworks

The misalignment between Scrum and Jira isn't really a Jira problem per se. It's a basic flaw in the ticketing paradigm itself, not Jira specifically, that often creates friction for many agile implementations. There are ways to work around the inherent friction, and you can make significant changes to the way Jira works by default, but any ticketing process inherently works against whole-team collaboration unless you actively, conscientiously, and continuously map your team-based agility and framework concepts onto a tool that doesn't natively track or measure work the same way Scrum does.

That doesn't mean you can't use Jira, or that you shouldn't. You just need to be aware of the disjoint between assigning tickets or tasks to individuals to be worked on independently, and the central premise of Scrum which is that the whole team collaborates together to build Increments that achieve a singular Sprint Goal that makes progress towards your Product Goal.

CodeGnome's Scrum Tautology℠ says: "Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal." (Jacobs, 2018).

Ticketing systems encourage you to focus on completing lots of tickets. If you use such a system, you must find a way to map your goals and team-based work onto the system, but there's no single best practice for doing that with Jira or anything else. That's where you need to leverage your team's commitment to continuous process improvement to find a way that works for your company culture and your project.


The term "artifact" doesn't originate with Scrum. It's been widely used in computing to refer to any of the "tangible by-products" created during software development. It comes from the same origins as the term from archaeology, where it refers to items made or shaped by humans. Your Jira tickets are an example of an artifact. The source code of the software system is another artifact. If you compile the source code into binary files, those are also artifacts. Any documentation - architectural or design documents, user guides, and so on - are also examples of artifacts.

The term "deliverable" comes from project management. It is used to refer to anything that is delivered to a customer or stakeholder. Most, if not all, deliverables are artifacts, but not all artifacts are deliverables. If you export your Jira issues and send it to a customer, that would be a deliverable. If you package your software source code and make it available to customers or users, that would be a deliverable. If it ends up in the hands of someone outside of the development team, it's a deliverable.

Although the concept of increments isn't unique to Scrum, it does have its own definition for "Increment", which can be found in the Scrum Guide. In Scrum, the Increment is a state of the product. When a Product Backlog Item meets the Definition of Done, a new Increment is created. The product has evolved, yet continues to maintain required functional and quality attributes. As more Product Backlog Items are complete through the Sprint, more Increments are created. The most recent Increment is inspected at the Sprint Review. The Increment is an artifact and, if it is made available to stakeholders, a deliverable, but it doesn't have to be made available.

  • On a related note, the words deliver, delivered, and delivering are used in the 2020 Scrum Guide, but not deliverable. Theoretically, the Product Goal is the closest mapping to "deliverable," but treating an Increment as a synonym for a deliverable encourages people to think in terms of delivering independent "increments of stuff" instead of building a coherent Sprint Goal. I'm not trying to split hairs with the definitions; it's just that I often see teams fall victim to the Dark Side of the Force when they think about "deliverables" instead of Product Goals or even whole Increments.
    – Todd A. Jacobs
    Jan 11 at 0:21
  • @ToddA.Jacobs I'd have to think about it more, but I don't know if I'd call the Product Goal a deliverable. Scrum.org has some examples of good Product Goals.. The only one that I'd consider a deliverable is Product Goal 1, which is to launch a website. But the real deliverable is the website itself. The other two example Product Goals aren't tangible things handed over. I think a better way is that a Product Goal expresses what the deliverable(s) are expected to enable or allow the customer to achieve.
    – Thomas Owens
    Jan 11 at 0:48
  • That's a fair point. I think the challenge then is that while you can say Increments are potentially-shippable units of value, I don't know that Scrum really addresses "deliverables" at all in the typical sense, except to say that Increments can be delivered. Since the OP is really asking about mapping such terms onto Scrum via Jira, I don't know that anything in Scrum is really a 1:1 match for "deliverable."
    – Todd A. Jacobs
    Jan 12 at 15:42
  • 1
    @ToddA.Jacobs That is true. Nothing is explicitly a deliverable. I think it's safe to assume that external stakeholders can at least see the Product Backlog, so maybe that's a deliverable. And whatever product is being created is probably a deliverable, too. But it's not explicit and I'm sure that someone can come up with a case where these things aren't.
    – Thomas Owens
    Jan 12 at 16:34
  • 1
    I updated my answer to take a swack at it. I think overall Increment is probably closest, but still not a 1:1 match. Product Goals could be structured as deliverables, but don't have to be; I tried to articulate that too. Thanks for making some great points!
    – Todd A. Jacobs
    Jan 13 at 20:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.