Artifacts
Scrum’s artifacts represent work or value in various ways that are useful in providing transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information needed to ensure Scrum Teams are successful in delivering a “Done” Increment.
Product Backlog
Owner : Product Owner
Influence : Scrum Master and Development Team
The product backlog is an ordered list of "requirements" that is maintained for a product. It contains Product Backlog Items that are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc. The features added to the backlog are commonly written in story format. The product backlog is the “What” that will be built, sorted in the relative order it should be built in. It is open and editable by anyone, but the Product Owner is ultimately responsible for ordering the stories on the backlog for the Development Team.
The product backlog contains rough estimates of both business value and development effort, these values are often stated in story points using a rounded Fibonacci sequence. Those estimates help the Product Owner to gauge the timeline and may influence ordering of backlog items.
The Product Backlog, and business value of each listed item is the responsibility of the Product Owner. The estimated effort to complete each backlog item is, however, determined by the Development Team. The team contributes by estimating Items and User-Stories, either in Story-points or in estimated hours.
The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists, and this results in a living document that is never complete until the product has expired or reached its end state.
Product Backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog grooming, items are reviewed and revised. However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform grooming itself. How and when grooming is done is decided by the Scrum Team. Grooming usually consumes no more than 10% of the capacity of the Development Team. The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping understand and select trade-offs, but the people who will perform the work make the final estimate.
User Stories
Owner : Product Owner
Influence : Development Team
User Stories are supporting artifacts for requirements. User stories are not expected to be a full and complete set of requirements. They are an anchor for a conversation. As a person who is creating and delivering requirements to a development team you may have further details written down, models created and rules listed. These are also useful and should be, like User Stories, used as supporting tools in a conversation with your developers.
Three key aspects of a user story are:
- The “user” of the solution
- The outcome you envisage from an interaction with the system, and
- The value this interaction/outcome is trying to yield.
User Stories must also contain acceptance criteria. This is used during the testing phases to ensure that the requirements are met for this story to be ready and meet the teams "definition of done" . Typically these should be listed on the same card, or on the back of the card as reference.
Users Stories can be written as a user or as a malicious party. Each of these types of stories offer a benefit. Malicious User stories can help you determine what holes your original storiest might have and are extremely useful for securirty based situations. User stories come in different sizes and shapes and are expected to be prioritised in order, based on value. (Value includes mitigating risk, so hard, but low reward stories may be addressed early.)
Typically User Stories are categorized into three types;
- Epic
- Theme (aka Feature)
- Story
Each of these labels represents a different class of granularity. Epics are huge and suited to things off in the distance (Think All Payment methods). Themes are things generally being worked on now or in the near future (Think Credit Cards) . Stories are what you take to the sprint (Think Visa or AMEX). Smaller classes of requirement fit into the larger ones. Think of Russian dolls. You can read more on these three classes of story elsewhere.
Sprint Backlog
Owner : Development Team
Influence : Scrum Master and Product Owner
The sprint backlog is the list of work the Development Team must address during the next or current sprint. The list is derived by selecting stories/features from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. This is done by the Development Team asking "Can we also do this?" and adding stories/features to the sprint backlog. The Development Team should keep in mind the velocity of its previous Sprints (total story points completed from each of the last sprints stories) when selecting stories/features for the new sprint, and use this number as a guide line of how much "effort" they can complete.
The stories/features are broken down into tasks by the Development Team, which, as a best practice, should normally be between four and sixteen hours of work. With this level of detail the Development Team understands exactly what to do, and potentially, anyone can pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed during the daily scrum, according to the set priority and the Development Team member skills. This promotes self-organization of the Development Team, and developer buy-in.
The sprint backlog is the property of the Development Team, and all included estimates are provided by the Development Team. Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.
Definition of Done
Owner : Development Team
Influence : Scrum Master and Product Owner
When the Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the “Definition of Done” for the Scrum Team and is used to assess when work is complete on the product Increment.
The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning Meeting. The purpose of each Sprint is to deliver increments of potentially releasable functionality that adhere to the Scrum Team’s current Definition of “Done.” Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.
Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together. As Scrum Teams mature, it is expected that their Definition of “Done” will expand to include more stringent criteria for higher quality.
Product Increment
Owner : Scrum Master and Development Team
Influence : Product Owner
The Increment is the sum of all the Product Backlog items completed during a Sprint and 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.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.
Burndown Chart
Owner : Scrum Master
Influence : Development Team and Product Owner
Various trend burndown, burnup and other projective practices have been used to forecast progress. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making.
The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burndown, for example the release burndown chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the alternative release burndown chart,which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline.
At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least for every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.
Scrum Board
Owner : Development Team
Influence : Scrum Master and Product Owner
Each row on the Scrum board is a user story, which is the unit of work we encourage teams to use for their product backlog. During the sprint planning meeting, the team selects the product backlog items they can complete during the coming sprint. Each product backlog item is turned into multiple sprint backlog items. Each of these is represented by one task card that is placed on the Scrumboard. Each task card starts on the Scrum taskboard in the “To Do” column.
The columns we generally see on a taskboard are:
- Story: The story description (“As a user we want to…”) shown on that row.
- To Do: Place for all cards that are not in the “Done” or “In Process” columns for the current sprint.
- Work In Process: Any card being worked on goes here. The programmer who chooses to work on it moves it over when she's ready to start the task. Often this happens during the Daily Scrum when someone says, “I'm going to work on the boojum today.”
- To Verify: A lot of tasks have corresponding test task cards. So, if there's a “Code the boojum class” card, there is likely one or more task cards related to testing: “Test the boojum”, “Write FitNesse tests for the boojum,” “Write FitNesse fixture for the boojum,” etc. Some task cards don't often get corresponding test cards (“Fix Bug #321 in Bugzilla”) so those are placed in the “To Verify” column.
- Done: Cards pile up over here when they're done. They're removed at the end of the sprint. Sometimes we remove some or all during a sprint if there are a lot of cards.