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:
registration pagelogin pageIn 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.
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.
"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:
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.
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:
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.
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.
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.
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.
