![]() Shall you redeem for a failed commitment?īut the most important reason for the change (which is a direct consequence of the former argument), is the misuse, and even abuse, that the word commitment has suffered during lots of so called “Scrum” projects. When a forecast doesn’t come true, it is easier to think about matters such as learning from the experience, improvement and - in one word - empiricism, which at the end is what Scrum is about. When a commitment is broken or not fulfilled, it is usual to expect some sort of accountability, fault, or even compensation. Continuous collaboration between the Development Team and the Product Owner thus leads to renegotiation of the scope of the Sprint Backlog during the Sprint if we pay attention to the meaning of the words, this would lead us to have a broken commitment versus a non-materialized forecast. The Scrum Team also knows that reaching the end of the Sprint without having done all the initially selected Product Backlog Items sometimes just happens, despite its best efforts. This is much closer to how an experienced Scrum Team works, where everybody knows that the initially crafted Sprint Backlog - and thus, the associated list of Product Backlog Items - is subject to change as more becomes known throughout the Sprint. On the other hand, the chosen alternative “forecast” has to do with making assumptions based on reliable information and evidence. When we use the word commit, we can be easily biased towards that duty-obligation-promise way of thinking. A Sprint Backlog is complex enough that uncertainty is always present, and common sense tells us that we shouldn’t promise what we are not sure to be able to deliver. But reality keeps on showing us that it is difficult, if not impossible, to always fulfill this self-imposed commitment without making compromises to quality. After committing to deliver a list of Product Backlog Items, the Scrum Team, foremost the Product Owner and especially the stakeholders may feel that there is an obligation to actually deliver all of them at the end of the Sprint. The word commitment usually relates to undertaken duties. There’s an immediate reason for the change, which has to do with the meaning of the words themselves. ![]() Why forecast is better suited than commitment? It may seem to be a simple wording change, but in fact there are strong reasons behind it, and surely it will have great implications. Scrum now encourages the Development Team to forecast which Product Backlog Items it will deliver by the end of the Sprint. ![]() We used to say that the Development Team commits to which Product Backlog Items it will deliver by the end of the Sprint. One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |