Scrum Artifacts

Scrum has three Artifacts.

1. Product Backlog
2. Sprint Backlog
3. Product Increment

Product Backlog

Product backlog starts with Product Vision. Product Backlog is an ordered list of customer requirements and a single source of requirements for the given product i.e. there is only one Product Backlog for a product under development. Product Owner is responsible for the Product Backlog.

Product Backlog is never finalized. It continuously evolves as the product and the project environment evolves. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.
The Product Backlog lists all features, functions, requirements, enhancements, and fixes that needs to be developed for the product release. Product Backlog items have the attributes of a description, order and estimate.

The high priority items in the Product Backlog are fine grained and have more details as well as accurate estimates because of the greater clarity and details of those items. Items on the lower priority are big items with high level estimates. As Team gets more clarity on lower priority items, these items are further split in to small items. The Development Team is responsible for the estimates of the items in the Product Backlog.

Product Backlog is DEEP

DETAILED APPROPRIATELY: 

The top priority items of the Product Backlog are more fine-grained and detailed than the lower priority items, since the former will be worked on sooner than the latter. 

ESTIMATED: 

The items in the Product Backlog are estimated. The items at the top of the backlog have more accurate estimates. The lower priority items are estimated at high level and can be re-estimated as team gets more information.

EMERGENT:

Product backlog is regularly refined as the Team learns and gets more information. Each Sprint, items may be added, removed, modified, split, and changed in priority.  Thus, the Product Backlog is continuously updated by the Product Owner to reflect changes.

PRIORITIZED:

Items in Product Backlog are prioritized or ordered in 1-N order. The Higher priority items should give more value than the lower priority items. Priority of items can be changed over a period of time

User Story

User Story is a short description of a requirement from user prospective. It is not a requirements document. It clarifies what the user will get. It represents a small feature that can be estimated and developed independently. It contains business requirements that have a high level description of a required functionality.

The User Story template should be like 

As a <role> I want <a feature> so that <reason, value>

Example - As a user, I want to cancel hotel reservation so that I can get a refund.

INVEST Model

User stories follow INVEST Model.

I – Independent: Should be self contained 

N – Negotiable: Up until they are part of Sprint, can always be changed and re-written

V – Valuable: Must deliver a value to a end user

E – Estimatable:  Team must be able to estimate the size of a user story

S – Small: Should not be so big as to become impossible to plan/task/prioritize with high degree of certainty

T – Testable: Must provide the necessary information to test it after development

Example of an User Story

As a user, I want to cancel a hotel reservation so that I can get a refund.

• A premium member can cancel on the same day without a cancellation fee
• Non-premium member is charged for the same day cancellation with a 10% cancellation fee
• An email confirmation is sent to the customer
• The hotel is notified of the cancellation
• Reservation can be can cancelled a  day before by all the members without any cancellation fee

USER STORIES ARE VERTICAL

Bad User Story

Good User Story

User Stories should be vertical. There should not be separate User Stories for User Interface, Business Layer and a Database. A Good User Story should cover all areas including User Interface, Business Layer, Data Access Layer and a Database. 

Sprint Backlog

Sprint Backlog is a subset of Product Backlog. The items in the Sprint Backlog are selected by the Development Team and it is a forecast by a Development Team about what functionality will be delivered in next Product Increment. It also contains defects and unfinished work. Each item in Sprint Backlog should be small enough so that it can be delivered in a sprint. A general guideline is to complete it in ¼ th or less of sprint of the whole team. Once the Sprint starts there should not be any changes in Sprint Backlog items. If the new requirements emerge during the Sprint then those requirements should be added to the Product Backlog but current Sprint Backlog should never change.

Product Increment

The Product Increment is the sum of all the items completed during a Sprint and the items completed in previous Sprints. Each Product Increment is additive to all prior increments and thoroughly tested, ensuring that all the increments work together. At the end of Sprint, the Product Increment must meet the definition of "Done" agreed by the Scrum Team. The Product Increment must be in "Ready to Ship" condition. 

Definition of Done

It is a list of requirements that software/user story must adhere to for the team to call it complete. While the DoD usually applies to all items in the backlog, Acceptance Criteria are applicable to a specific user story. In order complete the story; both the DoD and acceptance criteria must be met. Unless this list is done the Product Increment is not done. Before the start of the Sprint the Product Owner and the Team should agree on Definition of Done. It should not be changed during the Sprint. If changes need to be done then it should be done between Sprints.

Example of DoD

• Code builds without warnings
• Code unit tested
• Deployed to system test environment and passed system tests 
• Build pushed to demo server