A different kind of artifact...

A different kind of artifact…

Scrum is nothing if not simple. Three roles, four or five events depending on what you count and  . . . three artifacts.  The Scrum artifacts are deceptive in their nature as each artifact plays double, triple or even quadruple duty across the lifespan of the project. When using Scrum, the deliverables must evolve.

The artifacts identified in Scrum are:

  1. The Product Backlog. This includes all of the known units of work in priority order.  In a perfect world, the team would already know everything that needs to be delivered and capture it on the product backlog at the beginning of the project.  Classically, project teams invest significant efforts in defining as many requirements as possible, and then they put that list under change control (sometimes the level of control was quite draconian).  In Scrum, the product backlog represents the antithesis of the classic requirement document, at least from the perspective of process. If an initial product backlog does not exist, most projects begin with a short time box to begin the development of a backlog.  Sprint teams begin development at the end of the time box or sooner if possible. The backlog is always prioritized (highest priority to lowest) with the units of work near the top broken down to a point that they can be completed during a single iteration.  As the project begins and the backlog begins to be used, evolution begins.  Existing units of work are continually refined and groomed, while newly discovered units of work are added to the backlog.  The product owner owns the product backlog.  The product owner needs to have perfect transparency into the list as he or she will need to review and refine the prioritization as the team gains knowledge about the solution and the market place.
  2. The Sprint Backlog. It is the breakdown of tasks and activities required to deliver the units of work the team committed during the sprint.  The sprint backlog exists only for the time box beginning with sprint planning and ending with the team retrospective.  The sprint backlog is first developed during sprint planning and then refined by actual events and planning that occurs during the daily meeting.  A sprint backlog that does not evolve is a failure.  Colin Powell, US General and statesman, said “No battle plan survives contact with the enemy.”  The sprint backlog is the team’s battle plan.
  3. The Increment. The increment is the functionality completed during the sprint.   Assuming you are involved in a software project, the gauge as to whether a sprint has met its goals is whether functional software is delivered that satisfies the units of work that the team committed to delivering.  Satisfied means that the software meets the definition of done (a solid definition of done is that the code is written, documented as required, tested and is defect free) and is potentially implementable.

All three Scrum artifacts evolve.  The increment and the product backlog will change over the life of the project.  Inspecting the functionality delivered by the increment provides value to the organization and tangible proof of progress that a schedule or status report can’t provide. The sprint backlog will evolve based on the daily re-planning the team performs as they work toward the goal of delivering the increment needed to satisfy the commitment made during sprint planning.  The artifacts in Scrum are living deliverables in a way that no requirements document or project schedule could be in classic software development techniques.