Scrum compact – Part 4: Artefacts
The product backlog is the list of desired changes and innovations for the product. These include new features, bug fixes, documentation changes, and more that are considered useful and value added. We refer to these entries as Backlog Items or User Stories. The list of user stories is arranged in such a way that the most important Story is at the top. This should be processed by the team next. Just below is the user story that the team should implement second, and so on. Because User Stories are soon being worked on in the product backlog, they should be compact and easy to understand for the whole team. User stories further down in the list may be more extensive and less precise. Over time, they will be detailed and possibly split into several user stories.
The sprint backlog is the team’s to-do list for this sprint. This list must be completed at the end of the sprint. The Sprint Backlog contains all the user stories planned for this sprint by the team for implementation as well as the associated tasks. A user story is implemented by processing the assigned tasks. A task is usually assigned to a team member, while a user story is the responsibility of the entire team.
A burn chart illustrates the relationship between time and functionality. The time is displayed on the horizontal axis and the functionality on the vertical axis. A Burup Chart shows how much functionality the team has implemented within a given time period. Every time something new has been done, the line moves up a bit. A burndown chart illustrates how much remains to be done. In general, it is expected that the list of remaining features to perform will decrease over time as the team implements the desired functionality. Sometimes the list changes suddenly, for example, when scope has been added or removed. These events appear as vertical lines in the burndown chart: a vertical increase indicates that functionality has been added. If the line goes down, the functionality has been removed.
The simplest Task Board consist of three columns with the headings:
- To Do
- In Work
A task board is placed in the room so that each team member has access to it. If the teams are distributed locally, electronic, web-based task boards help. The tasks are moved on the board, so that it is visible, which tasks are done, which are in progress and which have not yet been received. This visibility allows the team to assess their current situation well and adjust if necessary. The board also helps stakeholders and the product owner to monitor project progress.
Definition of Done
In a project, it is important that everyone involved has a common understanding of what is done. If the programmer is done with the creation of the source code and his test, the software can not be handed over to the customer for a long time. If the tester has come to a positive conclusion with his examinations, this does not mean that the system can go into productive operation. A salesman understands “ready” that he can sell the product to customers and they can use it immediately.
To avoid confusion resulting from this different understanding, Scrum teams clearly define the meaning of the word. A typical catalog of criteria looks like this:
- Code written
- Code reviewed
- Regression tests passed
- Passed by the customer
This list of things to do before a user story can be described as finished implemented is called “Defintion of Done”. Many teams have their definition of done checklist hanging next to their task board.