Scrum Artifacts

Scrum artifacts of management activities are created to increase transparency of information related to ]project delivery and provide opportunities for inspection and adaptation.
There are six artifacts in Scrum:

  • Product Backlog: an ordered list of everything , aka all of the stories, that might be needed in the final product
  • Sprint Backlog: selected items (stories) from the Product Backlog to be delivered through a Sprint, along with the Sprint Goal and plans for delivering the items, aka the tasks needed to complete the Sprint Goal
  • Increment: set of all the Product Backlog items completed so far in the project, up to the end of a certain Sprint
  • Definition of Done: shared understanding of what it means for a story to be considered complete
  • Monitoring Project  Progress: performance measurement and forecast for the whole project
  • Monitoring Sprint Progress: performance measurement and forecasts for a single Sprint

Product Backlog

Product Backlog: ordered list of stories.
Product Backlog description:

  • The Product Backlog is an ordered list of everything that might be needed in the final product of the project (a wishlist of the expected final product).
  • All items are described in simple business language (non-technical) and all of them are presentable to every stakeholder.
  • Every requirement and every change in the project will be reflected in the Product Backlog.
  • The Product Backlog is dynamically changing and improving; it is never complete.
  • The first Sprint can be started as soon as the Product Backlog has a sufficient number of stories defined and we do not wait until the Product Backlog is complete to start delivering the items
  • The Product Owner sets a number of factors (ROI) to determine the value of each item for the business, summarized into one importance value shown with each item.
  • The Product Backlog items are ordered based on their value, with the higher items at the top so it will be sooner delivered by the Development Team.
  • Top backlog items should be clear and detailed.
  • Each Product Backlog item should have a work estimate completed by the Development Team, to determine the team’s capacity for a given Sprint (number of items that could be completed).

Information available for a single Product Backlog item in a typical Scrum tool like JIRA include:

  • Story Name: the user story itself  e.g. "As a user I want to login to my account to get access to my data"
  • Story Description: all the relevant information about the story so that the whole Scrum Team can have access to it.
  • Story Complexity: defines the nature of the story and used for Sprint Planning (usually the more complex a story is, the more uncertain its estimate would be)
  • Story Estimate: estimated volume of the story determined by the Development Team.
  • Assignments: story can be assigned to any person in the team (even if whole Scrum Team would remain accountable for it)
  • Tasks: breakdown the story into tasks (detailed planning) and track them separately.
  • Comments: each member of the Scrum Team can leave comments and collaborate with others

Optional fields:

  • Categories: easy way to ease of access and maintenance when multiple stories in the backlog (act as a normal WBS)
  • Colours: You can set different colours to each story to differentiate them visually in the Scrum board. This is another way of grouping/categorizing items.
  • Tracker:  You can record time spend on each story for further analysis, refining estimates, billing, etc.
  • Attachments: attach relevant documents and use the software as a document management tool.
  • Alerts: optional custom alerts can be set here
  • Due Date: optional custom due dates to track stories
  • custom fields

NOTE: Collaboration features are more important when the Scrum Team is not co-located and traditional ways of collaboration are not possible.
Product Backlog process guidelines:

  • The Scrum Team should add details, estimates, and order to the Product Backlog items all the way through the project, which is called Product Backlog grooming and it should not consume more than 10% of the time of the Development Team.
  • The Product Backlog is created more based on discussion rather than documentation.
  • The Product Backlog items (aka stories) should be easy to understand for non-technical stakeholders.
  • It is common to break the large stories into two or more stories later.
  • There should be only one Product Backlog, no matter how many Scrum Teams are working on the project, as the Backlog is a representation of the scope of the final product.

Sprint Backlog

  • The Sprint Backlog is created during the Sprint Planning event which is the first event in a sprint.
  • The Sprint Backlog is frozen (means that items cannot be added or removed during the Sprint) after the Sprint Planning and the Development Team will focus on delivering an Increment of Done based on this plan.
  • It might be necessary to get more information, justify, or clear some of the items during the Sprint, which should be done in the presence of the Product Owner.
  • The detailed plan which is normally not complete at the end of the Sprint Planning will become more complete as the Sprint continues.

The Sprint Planning event consists of the following:

  • Backlog stories: a number of items selected from the top of the Product Backlog, based on their estimated work and the estimated capacity of the Development Team
  • Sprint Goal: help describe the real meaning of the items and direct the efforts of the Development Team
  • Detailed plan: for delivery of the items and realization of the Sprint Goal during the Sprint

Increment

Increment description:

  • An Increment is a sum of all completed Product Backlog items at the end of a Sprint.
  • Each Increment must be Done and releasable.
  • The Product Owner may or may not release a certain Increment, but it should be releasable (shippable).
  • The number of stories in the Product Backlog decreases Sprint by Sprint, as the number of features in the Increments increases.
  • The Increment concept is cumulative meaning that each Increment also contains the features of the previous ones.

Definition of Done

DOD description:

  • There should be a shared understanding of what it means for a piece of work to be Done.
  • This definition of Done must be discussed and agreed upon by the Scrum Team at the beginning of the project so that future Increments would be releasable.
  • When multiple Scrum Teams are working on a single project, it might not be possible to use the same definition of Done for all teams (might be working on items of different natures) so  each Scrum Team will define its own definition of Done and delivers its items based on that definition.
  • The integration of those definitions of Done should be capable of creating a potentially releasable Increment in the project level.

Monitor Product Progress

Monitoring Project Progress description:

  • The Project burn-down chart helps visualize progress of the whole project
  • The Product Owner is responsible to monitor the progress of the whole project toward its goal.
  • This should be done at least once per Sprint Review.
  • The Product Owner determines the amount of remaining work and compares it to the remaining work of the previous Sprints, and forecasts the completion date of the project.
  • All stakeholders should have access to this information.
  • The project burn-down chart shows the amount of remaining work, instead of the amount of completed work; therefore, the line for actual performance goes downward as we proceed and the faster it goes down, the happier we will be!
  • The vertical axis (remaining work) shows the amount of work (which is a sum of all the estimates for each item in the Product Backlog), and the horizontal axis shows the amount of time passed from the beginning of the project or the number of Sprints passed.
  • We usually add another line to acts as our planned progress which represent the uniform distribution of the volume of the work across the initially estimated number of sprints

Monitor Sprint Progress

Monitoring Sprint Progress description:

  • Besides the monitoring done for the whole project, we should also monitor the progress of each single Sprint throughout its life.
  • This is the responsibility of the Development Team.
  • It should be done at least once per Daily Scrum.
  • This information is used to calculate the likelihood of achieving the Sprint Goal and completing all items of the Sprint Backlog.
  • The Sprint progress information can be represented by a burn-down chart, and this chart can be a part of the Sprint board, where everyone can see.