Many Scrum teams have a task board in their workspace on which they visualize their tasks and requirements. These boards represent the team’s work process and the flow of requirements through the different process steps. Often there are also the states “ToDo”, “Doing” and “Done”. The use of these terms as part of the development process is not wrong, but in the environment of Scrum they have a different meaning. This article explains the relationship between ToDo, Doing, Done and the three Scrum artifacts.
Scrum is not a Process
Many Scrum teams have a task board in their workspace on which they visualize their tasks and requirements. These boards represent the team’s work process and the flow of requirements through the different process steps. Often there are also the states “ToDo”, “Doing” and “Done”. Such boards can look like the following.
At the same time I experience statements like “We have introduced the Scrum process, […]”, “We have to optimize our Scrum process, […]” or, my absolute favorite, “We have adapted the Scrum process at our company, […]” in many job postings, discussions and talks. Just one look at the Scrum Guide tells us that Scrum is not a process.
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Scrum merely defines a time frame for our work, a timebox. Within this timeframe, various events such as Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective are mandatory. This timeframe in combination with the events forms an agile implementation of the PDCA cycle. However, it is not described how to work within the timebox.
A process, on the other hand, is an exact description of all steps, activities and rules according to which a requirement shall/must be processed in order to be transformed into a product. Since Scrum does not define any of these things Scrum is not a process. But if Scrum is not a process, what meaning do the words ToDo, Doing and Done have in this environment? To understand this we first have to take a closer look at the three Scrum artifacts.
The Three Scrum Artifacts
Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.
Basically the three artifacts are containers for the work done and the value delivered by a Scrum team. The diagram from Scrum.org shows the connection between the already mentioned Scrum Team, the Scrum Events and the Scrum Artifacts. As you can see, the Scrum universe knows three artifacts. These are the Product Backlog, the Sprint Backlog and the Increment. Let us take a closer look at each of the three artifacts and their definitions from the Scrum Guide.
The Product Backlog
The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. […] The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.
This means that the Product Backlog is an already filtered list of requirements that are actually needed in the product. Therefore feature requests, bug tickets and everything else must be checked before they are added to the Product Backlog. If a request is not needed or does not provide any value, which is basically the same, it is dropped. As a result, the Product Backlog contains all the items that are still to-do for the product.
The 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 realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment. The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal.
As the Scrum Guide tells us, the Sprint Backlog is a selection of Product Backlog items that are needed to achieve the Sprint Goal of the active Sprint. This means that each item of the Sprint Backlog is part of what the Scrum Team is currently “doing”.
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” […] The increment must be in useable condition regardless of whether the Product Owner decides to release it.
As you can see, all the work completed by the team and added to the product is part of the increment. In other words, all parts of the product that have been released must have been “done” by the team at some point in the past.
ToDo, Doing, Done und the Three Scrum Artifacts
In the previous paragraphs the three Scrum artifacts, their content and meaning were explained. Now that we have gained knowledge about the artifacts it is easier to understand the meaning of ToDo, Doing and Done in a Scrum environment.
All items in the Product Backlog are things that have to be “done” for the product in the future. The Sprint Backlog contains all things that the Scrum team is currently “doing” to achieve the active sprint goal. Finally, the increment contains all the work the team has “done” in the past to expand and improve the product.
Even if your team may use states like “ToDo” or “Done” within the workflow or development process, the meaning of these words is slightly different in a Scrum environment. We have seen that “ToDo”, “Doing” and “Done” are closely related to the three Scrum artifacts. This does not mean that your team should not use these terms as part of their workflow. This is also possible. Just make sure that the difference between something that is a “to-do” with respect to the product and something that needs to be done in a sprint is a little different. Clarity of mind provides clarity of speech, and clarity of speech promotes clarity of action. Make sure that your team is doing the right things and you will be able to build the right product.