pricetobook ratio Commitment vs. Fo(3)

If we have a look at the Development Team, many times the situation is not better. The team takes the commitment as a venture aimed at delivering every single bit of functionality which was promised at the beginning of the Sprint - once again, at any price. The only indicator for success is reaching the X-axis in the Sprint Burndown, the sooner the better, and sometimes even at the expense of software quality or the real business value being delivered.

I frequently find Development Teams, whether inexperienced or with a pretty broad Scrum background, putting the fulfillment of the entire commitment above anything else. They take it as a replacement for the real goal (which we are going to refer to in a moment). If they fail the commitment, they will express - maybe at the Retrospective – their disappointment with themselves, or try to find someone to blame inside the Team, instead of taking the opportunity to inspect, learn and adapt to improve for subsequent Sprints.

Either way, whether the commitment concept is abused by the business people or by the developers themselves, the usual victim is product quality, as Ken Schwaber himself has repeatedly pointed out.

The Development Team is pushed under the wrong kind of pressure, and the team members find themselves struggling to deliver each and every one of the selected Product Backlog Items by means of rushing, taking shortcuts, accumulating technical debt and not fulfilling the Definition of Done.

As a logical consequence, the Development often starts to pad its estimates to avoid the permanent pressure vise. Hopefully, getting rid of the word commitment in favor of forecast will help Scrum Teams avoid these pitfalls, and focus on what really matters.