As I promised in my previous articles, Roles in Scrum and Events in Scrum, I’m following up with a related article on Artifacts in Scrum.
In Scrum there are three tangible deliverables, called artifacts. These artifacts consist of the requirements for the overall project, the requirements for each piece of the project, and the project itself.
image source:http://www.agile42.com/
Product Backlog
The Product Backlog is a prioritised list of requirements, everything that might be needed in the product. This list is the only source of requirements and the items of this list are called Product Backlog Items. The Product Backlog is dynamic in order to make sure that the product needs to be appropriate, competitive, and useful. The Product Backlog defines the “What” that will be built by the Team.
The Product Owner is responsible for the Product Backlog. He is responsible for its availability and prioritisation. The Product Owner knows the business value is set by him. The development effort is set by the Team.
The top priority Product Backlog Items drive the next development activities, the next Sprints. To be estimated by the Team, the higher priority items have more detailed information than lower priority items.
During Release Planning the Product Backlog Items are initially established and calculated. Afterwards they are updated in Sprint Planning or Backlog Grooming meetings.
image source:http://www.informit.com/
A typical Scrum Backlog contains the following types of items:
- Features : “As a shopper, I want to see my shopping cart in order to know the total price of my products”
- Bugs: “The shopping cart button is not displayed on the top menu, on the right of the My account link”
- Technical work: “Upgrade the version of the IDE”
- Knowledge acquisition: “Researching various JavaScript libraries for image library and making a selection”
A user story (Product Backlog Item) is an Agile software development tool used to capture a description of a software feature from an end-user perspective. A user story must contain enough information so that the developers can produce a reasonable estimate of the effort in order to implement it. An Epic contains many User Stories.
A good user story uses the “INVEST” model:
- Independent. Reduced dependencies = easier to plan
- Negotiable. Details added via collaboration
- Valuable. Provides value to the customer
- Estimable. Too big or too vague = not estimable
- Small. Can be done in less than a week by the team
- Testable. Good acceptance criteria
image source: http://blog.smaato.com/
The typical template has 3 parts: the title, the description (or body of the user story), and the Acceptance Criteria.
Acceptance Criteria are the conditions that a software product must satisfy to be accepted by a user, customer, or in the case of system level functionality, the consuming system.
Given some precondition When I do some action Then I expect some result
Acceptance Criteria types:
- Functional Criteria: specific user tasks, functions or business processes that must be implemented. Example:“A user is able to access the product details.”
- Non-functional Criteria: related to the design. Example: “Edit buttons should be yellow.”
- Performance Criteria: specific performance of a user story. Example: “The list of products should be displayed in less then 1 second.”
Sample User story
Title:
Search for products by products category.
Description:
As a product search user, I need the ability to search for products by category so that I can more efficiently refer products to categories.
Acceptance criteria:
The product search mechanism has the ability to enter a category.
The category search will have a list of product categories from which to select.
Searching via the product category will return a list of matching categories or a message indicating that there are no matches.
If there are more results than can fit on one page, the system will provide the capability to view the list in pages or sections.
Sprint Backlog
The Sprint Backlog is the set of Product Backlog Items selected for the Sprint plus a plan for delivering the product Increment and realising the Sprint Goal. The Sprint Backlog is the result of the Grooming and Sprint Planning meetings.
The items are assigned and estimated by the Team. The Sprint Backlog is property of the Team. The Team keeps the Sprint Backlog always up to date during the Sprint. Also the Team members must split the User Stories in small tasks in order to make sure they will implement all the Acceptance Criteria.
Often a Task Board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.
Product Increment
The most important Scrum artifact is the Product Increment. Each Sprint the development team produces potentially shippable product increment. This product increment must align to the development team’s “Definition of Done” and the result of this increment must be accepted by the Product Owner.
If everything was implemented and the Development Team has estimated well, the Increment includes all items (user stories), which were planned in the Sprint Backlog, tested and documented.
Definition of Done is a list of activities that add verifiable value to the implemented product.
The Team can have a Definition of Done for different levels:
- Definition of Done for a feature (story or product backlog item)
- Definition of Done for a sprint (collection of features developed within a sprint)
- Definition of Done for a release (potentially shippable state)
Magda Miu 