pricetobook ratio Commitment vs. Fo(4)

At a first glance, one evident drawback could be the difficulty in getting used to the new term. We could find it difficult to begin adopting “forecast” for upcoming conversations and writings, or to remember the reasons for the change when reading “commitment” all over the already written material. Well, I think that in fact it’s not that hard to get into the habit, and the potential benefits are well worth the effort.

Besides that, there may be another (apparent) obstacle. At first sight we may think - maybe some people are mistakenly already doing so - that changing commitment by forecast will drive Development Teams to believe that they can happily relax, and assume that they can finish any Sprint without delivering a usable increment of software. Since it’s only a forecast…it’s not our fault if we don’t manage to get any single item done, right?

Well…actually “commitment” remains there. As you can see for yourself, the Scrum Guide only refers to forecast when dealing with the list of Product Backlog Items selected for a Sprint. But for any hardly competent person working as a developer, commitment is still present in Scrum and, furthermore, in software development itself, at all levels:

At a personal level, developers worth that title will commit to be professionals, striving always to do their best at work, given the available environment and resources. Dan Pink describes this fact in his book ‘Drive’.

At the values level, any Agile developer will of course commit to value people, working software, collaboration, and responding to change. He will surely commit even further than that, and go for technical excellence, continuous learning and improvement, team building and the whole set of Agile principles.