Scrum Artifacts

Product Backlog

What: Dynamic Ordered List of known items needed to be delivered. It continuously evolves (prod & environment) Resp: PO: content, priority,ordering, availability Each Items: description, order, estimate, and value. Also sometimes test descriptions that will prove its completeness when “Done.” A good user story should be: “I” ndependent (of all others) “N” egotiable (not a specific contract for features) “V” aluable “E” stimable (to a good approximation) “S” mall (so as to fit within an iteration) “T” estable (in principle, even if there isn’t a test for it yet) A good user story should be: “I” ndependent (self contained) “N” egotiable (leave space for discussion) “V” aluable (add Value) “E” stimable (to a good approximation) “S” mall (so as to fit within a sprint) “T” estable (item should have enough information to be testable)

Example of a User Story:

1. “As a client, I would like to be able to make a purchase without log-in so that I don’t waste time I do not want to invest.”

2. More Description if applicable

3. Acceptance criteria:
User is offereed the option during checkout
User still needs to enter an email address
User must still be offered to be added to newsletter

4.Estimation: 3 Story Points

Monitoring Progress Toward Goals Various projective practices upon trending have been used to forecast progress, like burndowns, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.

Sprint backlog

What: Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.It is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting. The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

Monitoring Sprint Progress At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Increment The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.” An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it

Artifact Transparency: Definition of “Done”

When a Product Backlog item is described as “Done”, each team member must understand what “Done” means to ensure transparency. The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously “Done” increments. For example, in software, a Definition of Done may be: “Done means coded to standards, reviewed, implemented with unit Test-Driven Development, tested with 100 percent test automation, integrated and documented.” In a services context, it may be like this: “Done means every task under the User Story has been completed and any work created is attached to the User Story so the Product Owner can review it and make sure it meets his or her expectations.”