I have recently experienced a big confusion in the usage of the “Committed” status defined for PBI and bug workflow in the Azure DevOps Scrum process.
Even though the same DevOps Scrum process was followed by multiple dev teams, the way how was the “Committed” status used was completely different. Some dev teams used the status for work items that were planned into the sprint, other dev teams used it for work items that had their associated work already completed in the sprint. How is such an unfavorable discrepancy possible?
The word “commit” itself can be tricky, as it has more meanings, and the formulation “to commit something” is not the same as “to commit to do something.” Therefore, additional context to resolve the correct meaning is needed.
So let’s have a look into a documentation to find the exact description of the vague status.
What documentation says
The Scrum process in Azure DevOps Services is based on Scrum principles and values, in which the development team commits to which Product Backlog Items it will deliver by the end of the sprint (the “commit to” term was used in early versions of Scrum Guide). This is done during sprint planning in which the work is not yet done.
Wait! The meaning of “commit to” in Scrum is completely different from “commit” used by most source control systems (including Git provided by Azure DevOps Services) and what are developers used to for years. Because in source control, the “commit” is created in order to send changes from the working copy to the repository. Such activity indicates that work was already done (at least partially). That could mislead developers who are adopting the Scrum process and who often rely on documentation.
So let’s check the official Microsoft DevOps Scrum process workflow documentation. The definition of “Committed” status for PBIs and bugs is highlighted below:
Which seems to be obvious and perfectly compliant with Scrum principles, so how is possible that developers, during the adoption of DevOps Scrum process, were still confused with the status meaning even after reading of definition? To find the answer, I have tried out google.
Bingo! I have sated my curiosity. I have found that a very interesting change was done in March 2018 based on the reported issue of the confused user related to the description of “Committed” status.
Such a tiny change but with a possible big impact! Because the original meaning “The team updates the status to Committed when they decide to complete the work during the sprint” could be explained that such decision is made, when the work item is really completed in the sprint (and all associated work is checked into the repository).
Getting rid of confusing status
The “Commitment” term was replaced by “Forecast” in 2011 Scrum Guide in regards to which PBIs will be delivered by the end of the sprint with good reasons for it. Despite the old term is still widely used in the Scrum world.
But getting rid of “Committed” status in favor of e.g. “Forecasted” status for PBIs and bugs in Scrum workflow would be at least less confusing.
There are occasions when we have to move PBIs back from a committed state due to unforeseen circumstances. In these cases when the PBI is then committed again the committed date is still the original committed date and not the new committed date. This then causes confusion. How can I set the committed date for the PBI to the new committed date.