Artefacts & Estimation
The three things Scrum produces, the three commitments that give them meaning, and why planning is really just structured guessing.
The Three Artefacts
Each artefact represents work or value, and each is paired with a commitment to maximize the information it provides.
Product Backlog
Commitment: Product Goal
An emergent, ordered list of everything that might be needed in the product. It's never complete — it evolves as the product and environment evolve. Items higher up are clearer and more refined; the Product Owner orders the list by value.
Sprint Backlog
Commitment: Sprint Goal
The Sprint Goal, the Product Backlog Items selected for the Sprint, and a plan for delivering them. It's a real-time picture of the work the Developers plan to accomplish — updated throughout the Sprint as new information emerges.
Increment
Commitment: Definition of Done
A concrete stepping stone toward the Product Goal. Each Increment is additive and must work with prior Increments. To have value, it must meet the Definition of Done — multiple Increments may be created within a Sprint.
The Three Commitments
These give purpose to the artefacts above and anchor empiricism in something concrete.
Product Goal
The long-term objective for the Scrum Team. It describes a future state of the product that can serve as a target — and must be fulfilled (or abandoned) before pursuing the next.
Sprint Goal
The single objective for the Sprint. It gives the Developers flexibility regarding the exact work needed to achieve it, while creating coherence and focus.
Definition of Done
A formal description of the quality state required when a product Increment is 'Done' — e.g. unit tests pass, code is reviewed, acceptance criteria are met. If a work item doesn't meet it, it can't be released or even presented at Sprint Review.
"Planning Is Guessing"
Every plan is a forecast based on what you know right now — and what you know right now is always incomplete. You can fix the scope, fix the date, or fix neither — but you can't fix both scope and date and still call the result a guarantee. Once you accept that planning means estimating under uncertainty, the question changes from "how do we predict perfectly?" to "how do we get better information, faster?"
Release Burnup Chart
Instead of a single up-front estimate, Scrum teams track completed work Sprint over Sprint. Plot total scope against cumulative points done, and a trend line emerges — showing when the team is likely to reach a given scope at its current velocity. The forecast gets more accurate every Sprint, because it's based on real data instead of a guess made on day one.
Want the deep dive on relative estimation, effort points and why teams use Fibonacci numbers?
Read: Agile Estimation with Fibonacci Numbers