Scrum Artefacts

In the previous article we covered the different meetings we could have in a Scrum Project. In this article, we are going to look at the various artefacts that are maintained in any scrum project.  

Product Backlog

The product backlog is arguably the most important artefact for the scrum project team. The Product Owner maintains this backlog which contains the prioritized list of product features or functionality that need to implemented with higher priority items on the top. At the beginning of each iteration, the scrum team will pick up the top ranked items and work on them. Some important points about this product backlog include:

• It is a force ranked list of functionality with every item having its own priority
• No two items can have the same priority
• The list is visible for all stakeholders
• Any stakeholder including the scrum team, can add items to this list/backlog
• The product owner maintains the priority of the items in the backlog
• It is updated & refined regularly, preferably in each scrum sprint during the backlog refinement meeting

Product Backlog Item

As we just saw, the product backlog is a prioritized list of items and they are called Product Backlog Items. Each of these items could be individually built, tested and shipped. In most scrum projects, these items are often written as User Stories. Each story has its own detailed requirements as well clearly defined acceptance criteria. The stories are usually sized in such a way that a few members of the team can finish the story within a few days (at max within a single iteration). Some important points about these product backlog items include:

• It specifies the “What” aspect of the feature to be incorporated into the product
• It is usually in a User Story format
• Has specific and clear Acceptance Criteria
• Can be estimated & implemented by the team individually

In some cases, it may not be feasible for the team to build the user story in entirety during a single iteration. Such stories are called “Epic Stories” and are broken down into smaller more manageable sized child stories and each of these children are individually implemented by the scrum team.

Real Life Trivia: A Major point of contention between the scrum team and the product owner is often times the acceptance criteria for a user story. Experienced scrum masters will make sure that when a story is selected for development during a sprint, the story’s acceptance criteria is clearly and unambiguously defined. Some people also call this as the “Definition of Done” which the team needs to accomplish to say that the story development is completed. 

The Sprint Backlog

The spring backlog is nothing but the product backlog items that are shortlisted from the overall product backlog as the potential items for inclusion in the current sprint. This list is identified as part of the Sprint Planning meeting during the beginning of the Sprint. The Scrum team commits to a certain scope at the start of the sprint and focuses on getting them completed during the Sprint. These committed backlog items are usually categorized into 3 major groups – Tasks Not Started, Tasks In Progress and Tasks Completed. A sample backlog chart would look as below:

Some important points about the Sprint Backlog include:

• The backlog is decided based on the commitment by the scrum team and is often times negotiated to achieve certain business objectives as envisioned by the product owner
• The backlog does not change during the sprint execution
• If additional tasks are identified by the scrum team during sprint execution to meet the scope committed during the sprint, they will be added to the list
• The list is used as reference during the daily scrum/stand up meetings
• The list is transparent and visible to all team members

Some scrum teams use electronic tools to represent this sprint backlog while many scrum teams prefer the old school approach where team members put up sticky notes on a white board.

Real Life Trivia: In the “Ideal” scrum world, there is no such thing as a commitment from the team with regards to what will be delivered in a Sprint/Iteration. The team will make a best effort attempt at delivering the user stories identified as part of the sprint backlog and if they are unable to do so (for whatever reasons they may be) the unfinished go back to the backlog and may be prioritized again for continuation in the next Sprint. However, in “Real life” projects, we don’t have this luxury. As we are working toward a product goal (which invariably would have a client impact) the team is expected to keep their commitment for the Sprint and deliver the functionality that was planned during the iteration planning meeting.

Sprint Task

Once we have the committed backlog for a particular sprint, the team will start breaking down the backlog items into more granular tasks. The tasks will address the “How” part of achieving the “What” mentioned in the Product Backlog Item. Each of these tasks is typically 1 or 2 days’ worth of work and each PBI could have more than one team member working on their tasks collaboratively to achieve the PBI’s acceptance criteria. Some important points about the Sprint Tasks include:

• Each task would require a few days of work (Ideal recommendation is at max 1 or 2 days)
• The remaining effort is re-estimated daily for all tasks during the daily stand up
• Usually one member of the team will be primarily responsible for each of the tasks
• A single backlog item could require multiple sprint tasks like analysis, design, implementation, deployment, testing etc. They are all taken up during the same sprint by one or more members of the team collectively.

Sprint Burndown Chart

The Sprint Burndown Chart as the name suggests shows us the work progression by the team wherein we start off with the 100% pending work to be completed on Day 1 of the sprint and work our way towards 0% pending work on the last day of the sprint. Every day during the daily scrum/stand up meeting, the team will share updates regarding the completion of tasks and collectively the team works towards finishing all of the planned backlog items for a sprint by the end of the sprint. That is why it is called a “Burn Down” chart where we target to hit 0% pending work before the end of the sprint. A sample Burndown chart would look as follows: 

While the “X” axis is straight forward and has the dates for the iteration, you may be wondering what the numbers on the “Y” Axis of this chart represent. They represent the amount of work left.

Real Life Trivia: You might be wondering why does the burn down chart go up instead of down during the initial days of the sprint. That is because, when a sprint starts, during the first few days the team is still in discovery mode finding out more work items which would eventually need to be finished for the backlog item to be marked as “Completed”. Hence the small spike during the first few days and the gradual progression towards 0 as tasks gets completed one by one.

Some important points about Burn Down charts include:

• On a daily basis, this chart can show us the total work that still remains (in hours or days – depends on the teams preference) for a particular sprint
• The chart is updated daily and tasks are also re-estimated daily to ensure the chart is an accurate representation of the pending work
• It helps the team self-organize and focus on pending items

Real Life Trivia: In many organizations that have recently adopted scrum practices, the burn down chart becomes more of a management reporting tool rather than a tool to facilitate self-organization within the team. In such a case, this becomes more of an impediment to the team because people with authority over the team are constantly monitoring the progress and the teams efficiency could come down as a result of this constant supervision. In such cases, the Scrum Master should take the initiative to discontinue use of the burn down chart and allow the team to work without such distractions.

In some organizations, apart from the sprint burndown, they also track something called as a Release Burndown chart where they track the completion of product backlog items over the course of multiple sprints. As with any product, the product backlog grows constantly and it is very rare for this burn down chart to hit 0% pending stories because companies constantly enhance their products and it is more of a matter of priority where low priority enhancements will stay in the backlog and get replaced by higher priority enhancements.  Usually Scrum Teams will use the term called “Story Point” while estimating user stories as well as tracking completion. For a release level burn down the number on the Y axis could be Story Points left while for Sprints the Y axis could represent maybe Days or even a more granular measurement factor. People who are very fond of the Waterfall methodology (or are unable to forget it) may choose to have a burn down that represents pending work in Man Days even for Releases.

On a related note, In scrum projects the scrum master captures a metric called “Velocity” which signifies the number of story points of work completed by the team in each iteration. The average velocity of the previous iterations could be a decent yardstick for the management team to predict the potential number of sprints the team may need to finish the remaining items in the overall product backlog. Don’t worry, you will learn more about Velocity and Estimation very soon.