What are the artifacts in Kanban?

Question

Scrum has a number of well-defined artifacts, including:

• Product Backlog
• Sprint Backlog
• Burn-Down Chart
• Increment

What artifacts are essential to Kanban?

Answer 1

My answer is: there are no predefined artifacts in Kanban.

Scrum has predefined roles, events, and artifacts but Kanban doesn't. Kanban just describes 4 principles and 5 practices:

1. Start with existing process;
2. Agree to pursue incremental, evolutionary change;
3. Respect the current process, roles, responsibilities and titles;
4. Encourage acts of leadership at all levels;

---

1. Visualize the workflow;
2. Limit Work-in-Progress;
3. Monitor, measure and optimize workflow;
4. Make Process Policies Explicit;
5. Improve Collaboratively.

(You can read more here, for example).

but nothing about roles, events, or artifacts.

P.S. As I had written in a comment, a Burn-Down Chart is not a Scrum artifact. You can use a Burn-Down Chart within Scrum, but it is not a part of Scrum.

Answer 2

Scrum Artifacts: Burn-Down Charts Aren't Mandated

Before answering your question, it's worth noting that burn-down charts are not required artifacts within Scrum. While the use of such charts is quite common, the framework itself does not require them. They are therefore ancillary artifacts generated by particular implementations, rather than artifacts generated directly by the Scrum framework.

Kanban Artifacts

By definition, a Kanban system has only two defined artifacts:

1. The kanban itself, which is the board everyone thinks of when they think of Kanban-the-methodology.
2. The kanban cards that move around the board.

However, implementing the Kanban Method generally results in a host of ancillary artifacts including backlogs, maps, policies, graphs, and reports. While none of these artifacts are explicitly required by the framework, it's hard to imagine an effective Kanban implementation that doesn't at least generate some metrics and graphs to inspect cycle time, lead time, and other key performance indicators to monitor the health of the project or process.

---

NB: David J. Anderson's method requires that you visualize your workflow, but doesn't actually mandate the implementation of a Kanban system with boards and cards. The mechanism (and therefore the artifacts) for visualization are left up to the implementation.

---

To summarize, anything generated during the implementation of the Kanban system or method is an artifact. The typical system requires only the board and cards, while the method only requires a means to visually represent the work. Everything else is a practice or side-effect.

Answer 3

Instead of repeating what other contributed so far (and I agree with the notion of anything generated during the implementation/application of Kanban is an artifact by CodeGenome), I would like to highlight the concept of Theory of Constraints, which transcends the common usage of Kanban from visualizing flow to exploitation of bottleneck, leading to increase of throughput (or "the rate of producing output or increment").

When configured correctly, bottleneck becomes the artifact of the system under used (note: artifact could also mean "the non-true feature of the object under observation as a result of external actions"). In order to reveal the bottleneck, one has to review the existing system (e.g. cycle time, WIP, etc. Gemba walk plays a very big part here), provide focus on the bottleneck, exhaust it and continuously improve it until it no longer limits the throughput of the system.

The throughput of the system and quality of process, are equally important as the output of your work and its quality. I will recommend you to read Chapter 7 of Kanban in Action by Marcus Hammarberg and Joakim Sundén.