Artefacts to improve visibility
Artifacts are “evidence of human activity” and are used in Scrum to refer to the lists, boards, graphs and systems, being used to visualize and manage the whole Scrum process. They are “information radiators”.
An empirical process control like Scrum is supported by three pillars: transparency, inspection and adaptation. The transparency part is achieved partly by making select activities and meetings public and holding these regularly, but also through the information radiators, which we call Artifacts. The Artifacts are easy to understand and they are self documenting, making it possible for even the innocent by-stander to derive meaning from them. In Scrum a number of Artifacts exist.
Product Backlog
The Product Backlog is as mentioned before an ordered list of Product Backlog Items, individual deliverables that we want, but do not have yet. The items at the top are considered more desirable to start working on early compared to those further down the list. This ordering is made by the Product Owner, who owns the Product Backlog; only he may change the ordering of items, although anybody can add to the Backlog. At any time, the backlog is a snapshot of the current plan as defined by the Product Owner.
The Backlog will often be shown with sections for different releases or phases and within them different planned Sprints. There is typically also an out-of-scope section (stuff the Product Owner does not think will make it within time and budget) and one for new ideas or requirements.
The Product Owner constantly works on refining and prioritizing the Product Backlog. He gets help from the Team in this Product Backlog Refinement. Sometimes he has others in the organization helping him with this as well.
The Product Backlog shows the current plan and prioritization to everybody who is interested. It can be a physical board with post-it notes or index-cards, it can be a spreadsheet or it can be implemented in a dedicated system.
Sprint Backlog
When the Team has planned a Sprint they represent it in the Sprint Backlog: an artifact that shows the planned deliverables (Product Backlog Items) and a plan for the work in the Sprint. This is often implemented as a Task Board with post-it notes in the Team’s room. It is highly visible and documents the Team’s progress in real time.
Each Product backlog Item is typically broken down into smaller pieces of work, often referred to as tasks. Each piece of work can be in different states, typically as a minimum we have “Waiting”; “Progress” and “Done”. It is also quite common to have an area called “Blocked” meaning that the Team is waiting for something from outside the Team before completion is possible. Work is normally broken down until each piece (task) is small enough to only be in “Progress” one day.
It is common practice to record unplanned activities, e.g. by using differently colored post-its, as these often will present the most serious obstacles to the Team’s progress and constant improvement. They will need to be addressed, and making them highly visible makes the organization react to them. They will often be discussed during the Sprint Retrospective.
The Sprint Backlog may reside in an IT system, if the Team is not co-located, but a physical Task Board is considered by most Teams to be far superior; there is constant visibility.
The Sprint Backlog is owned and maintained by the Team.Together with the Daily Scrum, it is the way the Team shows the surrounding organization the progress being made, this generates trust. The Team updates the Sprint Backlog at least once a day, so that it is correct at the end of Daily Scrum.
The Improvement Backlog
It is common practice to have an Improvement Backlog but not considered mandatory. It is almost like the Sprint Backlog, but instead of displaying the work related to the product that the Team works on, it displays the things the Scrum Master works on to improve working conditions for the Team, so that they can reach their maximum potential.
The Improvement Backlog is a delicate instrument. By its sheer public existence it provokes action; making impediments visible will often start the process of removing them. Nobody wants to be on the Improvement Backlog as it can provoke antagonism and conflict. The Scrum Master has to handle this situation with finesse.
The Product Burndown
Stakeholders and the Product Owner often want to monitor the progress of the whole project and be able to make projections about when the project will finish, or alternatively how much can be achieved within a certain time frame.
It is common practice in Scrum to use a Product Burndown chart that shows how much work has been achieved and of course how much is left (based on the estimates) before a certain goal is reached. The use of this artifact is however not mandatory.
The Product Burndown records how much work is left for each Sprint. From this, the Team’s Velocity can be monitored: how much is the Team capable of doing per Sprint? If changes are implemented to the Team’s work environment, it is important to monitor if it indeed improves the Velocity.
Given a qualified estimate of the Team’s Velocity, predictions about estimated time of arrival can be made. It is good practise to provide predictions as a range.
It can also be recorded on the Product Burndown how much Business Value has been harvested, how much risk is in the estimates and so forth?
It is common to highlight items added or removed from the Product Backlog on the Product Burndown. In the same way, it must be noted on the Burndown if major re-estimation has changed the perspective, which is not to be confused with a change in the Team’s velocity. Sometimes the focus is only on the next phase or release, then we call this artifact the Phase or Release Burndow
Sprint Burndown
If the Sprint is long (like four weeks), the Team is big or the general complexity of the backlog items is rather high, then there may be a need for a Sprint Burndown chart to monitor progress within the Sprint, again this is not mandatory in Scrum. If the Team is uncomfortable about staying in control of progress or the Sprint often misses the goal; then they need the extra visibility and control of the Sprint Burn-down.
The Sprint Burndown records the number of Tasks not “Done” every day in the Sprint. It is then possible to make predictions about whether the Team will complete everything planned for the Sprint. This is based on assumptions of the speed with which the Team executes tasks.
It is common to identify and highlight new unexpected tasks added to or tasks removed from the Sprint, to prevent obscuring the progress by unplanned events.