In our series of articles on Scrum artifacts, we have already covered the Product Backlog and the Sprint Backlog. In this article, we will be looking at the Scrum artifact which gets only a few sentences in the Scrum Guide and which is often misunderstood - the Increment. In addition to this, we will also examine the importance of artifact transparency in Scrum and the Definition of Done.
Definition of Increment
The Increment is defined as a sum of the Product Backlog items that were completed within a single Sprint and the value of that was added to the product in previous Sprints.
While it seems like a simple enough definition, it still causes some confusion. The reason for this is the second part of the definition that introduces the value added by previous increments. For some people, this differs too much from the traditional definition of the word increment. Scrum.org has a very interesting discussion about this on their forum.
In essence, the second part of the definition simply points out that new functionalities or features should build on the stuff that already brings value to the product and that they should in no way jeopardize the functioning of the product as a whole.
The increment definition also adds that the increment has to be “Done” at the end of the Sprint. It is essential to understand that “Done” in Scrum is a specific concept which is introduced as the Definition of Done.
Definition of Done
The Definition of Done in Scrum is applied to Product Backlog items that are being worked on as part of a Sprint and to the Increment at the end of the Sprint.
This category is introduced to put emphasis on the Scrum Team’s collective understanding of what it means for a Product Backlog item or Increment to be done.
The Definition of Done is established by the Scrum Team as a unit and it can include anything and everything that the Team believes to be pertinent. For some Teams, the Definition of Done will entail different types of testing, while others may add certain regulatory requirements that have to be passed for the items and increments to be done.
The Definition of Done is also a useful tool that can help the team during the Sprint Planning meeting. Namely, this shared understanding of when a Product Backlog item is truly “Done” better informs the team on how much work they can pull into a Sprint.
Whereas the Scrum Guide does not prescribe what should be included in the Definition of Done and leaves this to the Scrum Team, it does say that the increment should only be considered “Done” if it is useable and potentially releasable.
It is up to the Product Owner to decide whether it will actually be released.
It is a common practice for Scrum Teams to add to their Definition of Done as time goes on, as the Team becomes better and as it discovers additional criteria that will increase the value of Increments and the product as a whole.
While there are many reasons as to why Scrum employs artifacts as one of its very few defined categories, the main purpose of Scrum artifacts is to make the work transparent for the Scrum Team and other stakeholders.
Namely, by inspecting the state of Scrum Artifacts, the team can make informed decisions to best optimize the value and reduce the risks involved in developing a product of any kind. In order for the team to be able to do that, the artifacts need to be truly transparent.
The person who ensures the transparency of Scrum artifacts is the Scrum Master. It is the Scrum Master who works together with the Product Owner, the Development Team and any other potential stakeholders to make sure all artifacts are as transparent as possible.
Ensuring the transparency of all Scrum artifacts is not an easy job and it requires a lot of dedication on behalf of the Scrum Master. A Scrum Master has to continuously inspect the artifacts and compare them to what is actually going. They also have to sense patterns and listen to what the Scrum Team is saying, including between the lines.
Visualization of the Product Backlog and the Sprint Backlog can also be of huge help. This is where a Scrum Board comes in.
Another big part of the picture when we are talking Scrum artifact transparency is the culture and the atmosphere within the team. Namely, all Scrum Team members have to feel free to try things out and make mistakes without being dragged over the coals. In Teams where this is not the case, people may find it in their best interest to keep certain details about Scrum Artifacts hidden.
And that’s never a good thing.
Author: Goran Prijić is the co-creator and Product Owner at VivifyScrum. He is also a Certified Scrum Master.