Backlogs, Boards and Increments: Agile Artifacts for Beginners
Learn the things agile teams look at every day: the product and sprint backlogs, task and kanban boards, the increment and the Definition of Done.
Get Agile · Last reviewed October 23, 2026 · 6 min read
Agile teams spend a lot of time looking at a few shared things: a list of upcoming work, a board showing what is in progress, and the finished pieces of the product itself. If you understand these, you can follow almost any agile conversation.
The 2020 Scrum Guide calls the official versions "artifacts" and explains why they matter: "Scrum's artifacts represent work or value. They are designed to maximize transparency of key information." In other words, they exist so that everyone is looking at the same picture when making decisions.
This guide covers the product backlog, the sprint backlog, task and kanban boards, the increment and the Definition of Done, with examples you can picture.
The product backlog: one ordered list of everything
The Scrum Guide defines the Product Backlog as "an emergent, ordered list of what is needed to improve the product." It is "the single source of work undertaken by the Scrum Team."
Agile Alliance's glossary fills in what goes on it: "new features, changes to existing features, bug fixes, infrastructure changes, or other activities that a team may deliver in order to achieve a specific outcome." The most common format for items is the user story, a short description of something a user needs and why.
Three ideas about the backlog help beginners the most:
- It is ordered, not just prioritized. Item one comes before item two. In Scrum, ordering the backlog is part of the Product Owner's accountability.
- An item on the backlog is an option, not a promise. Agile Alliance notes that the presence of an item "does not guarantee that it will be delivered," and that adding and removing items should be cheap and easy.
- Detail grows as an item gets closer. Items the team will work on soon should be small and clear; items far down the list can stay broad until they matter.
The Scrum Guide attaches a commitment to the backlog: the Product Goal, which "describes a future state of the product" and serves as the team's long-term objective. The work of adding detail, order and size to items is called refinement, which the guide describes as "an ongoing activity."
The sprint backlog: the plan for right now
At the start of each Sprint, the team builds a Sprint Backlog. The Scrum Guide says it is made up of "the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how)."
It is "a plan by and for the Developers" and is updated throughout the Sprint as the team learns more. Its commitment is the Sprint Goal, a single objective that gives the team focus while leaving flexibility about exactly which tasks get it there.
A simple way to remember the difference: the product backlog is everything the product might need; the sprint backlog is what the team is working on this cycle and how.
Boards: making work visible
A board is the most visible tool on most agile teams, and it comes in two common styles.
A task board, as Agile Alliance's glossary describes it, can be as simple as a whiteboard divided into three columns: "To Do," "In Progress" and "Done." Each task gets a sticky note or card that moves across as work progresses. The board is usually updated during the daily meeting and is commonly "reset" at the start of each iteration. Agile Alliance calls it an "information radiator," something that spreads useful information to anyone who glances at it.
A kanban board looks similar but works differently. According to Agile Alliance, it is not reset each iteration, its columns represent the stages a piece of work moves through, and each column may have a work-in-progress (WIP) limit. If the "testing" column has a limit of two, the team does not start testing a third item; it helps finish what is already there. Agile Alliance warns that kanban boards without enforced WIP limits lose much of their effectiveness.
The Kanban Guide (May 2025) calls the board the visualization of a team's Definition of Workflow and says "There are no specific guidelines for how a visualization should look." It also names four flow measures that Kanban teams must track: work in progress, throughput, work item age and cycle time.
Physical or digital? Agile Alliance notes that electronic boards suit teams with remote members, while physical boards keep the backlog "continuously visible and concrete." Many teams start with whatever the whole team will actually look at every day.
The increment: real, usable progress
The Increment is what the work produces. The Scrum Guide calls it "a concrete stepping stone toward the Product Goal" and adds: "In order to provide value, the Increment must be usable." Each Increment builds on all earlier ones, and a team can create several in one Sprint. They can even be delivered before the Sprint ends.
The key word is usable. Agile Alliance's glossary describes agile increments as "vertical" slices, where each version of the product adds something a user can see and use, rather than finishing one technical layer at a time.
For example, imagine a team building an online ordering page for a small bakery. A horizontal approach might spend weeks on the database before anything is visible. A vertical first increment might be a single page where a customer can order one cake for pickup. It is small, but someone can actually use it.
The Definition of Done: the quality bar
How do you know an item is really finished? The Scrum Guide's answer is the Definition of Done, "a formal description of the state of the Increment when it meets the quality measures required for the product." It puts it memorably: "The moment a Product Backlog item meets the Definition of Done, an Increment is born."
The rule is strict. If an item does not meet the Definition of Done, "it cannot be released or even presented at the Sprint Review." It goes back to the Product Backlog instead. If the organization has a standard, every team must meet it at minimum; otherwise, the team creates its own.
Agile Alliance's glossary captures the problem it solves: someone may be "done programming" without being done testing, documenting or making the work deployable, which teams sometimes describe as being "done" but not "DONE-done." It recommends keeping the list to the minimum generally required and displaying it where everyone can see it.
For example, a website team's Definition of Done might read: reviewed by a teammate, tested on a phone and a desktop browser, checked for basic accessibility issues, and published to the test site. Your team's list will reflect your own work.
Putting it together
Here is how the pieces connect in one cycle:
- The Product Owner keeps the product backlog ordered toward the Product Goal.
- At Sprint Planning, the team pulls top items into a sprint backlog with a Sprint Goal.
- The board shows each item moving from to do, through in progress, to done.
- Items that meet the Definition of Done become part of the Increment.
- The Increment is reviewed with stakeholders, and what the team learns flows back into the product backlog.
For a walk through the meetings where this happens, see our step-by-step guide to agile events for first-timers.
Key takeaways
- The product backlog is one ordered list of options; items gain detail as they near the top.
- The sprint backlog is the Developers' plan for the current Sprint: a goal, selected items and tasks.
- Task boards reset each iteration; kanban boards show continuous flow and depend on WIP limits.
- An increment must be usable, and each one builds on the last.
- The Definition of Done is the shared quality bar; unfinished work goes back to the backlog.
Sources
- Ken Schwaber and Jeff Sutherland, The 2020 Scrum Guide (November 2020)
- Agile Alliance, Glossary: Product Backlog
- Agile Alliance, Glossary: Task Board
- Agile Alliance, Glossary: Kanban Board
- Agile Alliance, Glossary: Definition of Done
- Agile Alliance, Glossary: Incremental Development
- John Coleman and Daniel Vacanti, The Kanban Guide (May 2025)
Spotted something out of date? Let us know.