After Roles in Scrum and Events in Scrum, we’re following up with a related article on Artifacts.
In Scrum there are three tangible deliverables, called artifacts. They consist of the requirements for the overall project, the requirements for each piece of the project, and the project itself.
Image source: hhttps://www.agile42.com/en/
Product Backlog
The Product Backlog is a prioritized list of product requirements that defines the “What” that will be built by the Team. This list is dynamic in order to make sure that the product is appropriate, competitive, and useful. The Product Owner is responsible for the Product Backlog’s availability and prioritization.
The Product Owner is the most qualified to determine what items need to be implemented with priority, based on his knowledge of the market and ability to assess potential business value of each new feature. The Team members then assess the development effort needed for each item and determine what can be implemented during the new Sprint.
The top priority Product Backlog Items drive the next development activities, the next Sprints. To provide the Team with as much information as possible to base their assessment on, the higher priority items are more detailed than lower priority ones.
The Product Backlog Items are first established in the Backlog Grooming meeting, updated during Sprint Planning and finally evaluated during the Release Planning meeting.
Image source: https://www.informit.com/
A typical Scrum Backlog contains the following types of items:
- Features – e.g.: “As a shopper, I want to see my shopping cart in order to know the total price of my products”
- Bugs – e.g.: “The shopping cart button is not displayed on the top menu, on the right of the My account link”
- Technical work – e.g.: “Upgrade the version of the IDE”
- Knowledge acquisition – e.g.: “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 several User Stories.
A good user story uses the “INVEST” model:
- Independent. Reduced dependencies = easier planning
- Negotiable. Details added through collaboration
- Valuable. Provides value to the customer
- Appraisable. Too big or too vague = impossible to assess
- Small. Can be done in less than a week
- Testable. Good acceptance criteria
Image source: https://www.smaato.com/blog/
The typical template has 3 parts: the title, the description (or body of the user story), and the Acceptance Criteria.
The Acceptance Criteria are the conditions that a software product must meet in order to be accepted by a user, customer, or in the case of system level functionality, the consuming system.
Given a precondition When I perform an action Then I expect a result
Acceptance Criteria types include:
- Functional Criteria: specific user tasks, functions or business processes that must be implemented – E.g.: “A user is able to access the product details.”
- Non-functional Criteria: related to the design – E.g.: “Edit buttons should be yellow.”
- Performance Criteria: specific performance of a user story – E.g.: “The list of products should be displayed in less than 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 access 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 accomplishing the Sprint Goal. The Sprint Backlog is the result of the Grooming and Sprint Planning meetings.
The Team estimates and assigns the items, owns the Sprint Backlog and keeps it up to date during the Sprint. The Team members must split the User Stories into small tasks in order to make sure they will implement all of the Acceptance Criteria.
A Task Board is often used to monitor and update the tasks’ statuses during the current sprint (“to do”, “in progress” and “done”).
Image source: http://sharepointrun.com/
Product Increment
The most important Scrum artifact is the Product Increment. During each Sprint the development team produces a potentially shippable product increment, which must align to the development team’s “Definition of Done”. The result of this increment needs to be accepted by the Product Owner.
Image source: guntherverheyen.com
If all requirements were implemented within the estimated time-frame, the Increment will include all items (user stories), that 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 establish a Definition of Done at each of the following 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)
With this post we wrap up our introductory series on Scrum. If you’ve enjoyed learning about Scrum’s roles, events, artifacts, and the rules that bind them together, stay tuned for more advanced articles in the future.
