50 shades of “done” with the Result Chain

Well, maybe not 50. Anyway…

Have you ever gotten the question: “when will you be done?”. I think most of us have. If we work in a team where other people are dependant on us, we must be able to indicate when the work we do is done.

But, what does it actually mean to be “done”?

In agile practices, teams are encouraged to discuss what “done” means and come up with a shared definition. This is usually a checklist with things like:

• The code has been reviewed by a peer.
• All tests are run and show green (tests pass).
• Accepted as done by the Product Owner.

However, checking this list this does necessarily mean we are fully done. To know that, we must ask ourselves: why did we do the work to begin with? What was the desired result of the work?

To help us answer this question, we can use the result chain:

This very simple, but powerful model (that goes by many names, like Logical Framework Model, Kellogg Model and a few others) tells us how the work we do leads to the desired result (thus “result chain” — it’s the chain that’s needed to achieve results) in the form of a system level impact.