A short while ago I read a post by Skip Angel that talked about delivering on your promises . It reminded me of a situation a colleague told me about where a scrum team was under-promising and not telling the product owner, so that they had a better chance of delivering or over-delivering. I posted a description of the situation to the scrumdevelopment newsgroup.

In the discussion that followed, Jef Newsom described the act of under-promising and over-delivering as a "process smell". He said "the intent is good, but the means is deceptive". It indicates "that you aren't comfortable being honest with the parties to whom you are committing to deliver", i.e. to the product owner.

It's the product owner's responsibility to decide on the content of a sprint based on business value and cost, given in terms of estimates provided by the scrum team. It's the scrum team's responsibility to provide a cap on the amount of work assigned to a sprint based on their velocity. To paraphrase Ron Jeffries - you can't put 10lbs of shit in a 5lb bag. When the content of a sprint is agreed, the product owner must understand that it's an estimate and not a promise that it will all be delivered .

When the product owner wants to know what will be done by the release date and what will not be done, Ron Jeffries says "refer him to the burndown chart on the wall". Given empirical estimates and the tracking information produced by agile teams, the information in the burndown chart should be good enough, in most circumstances, to plan release dates by "drawing a line about there" in the product backlog.

The lessons to learn from this thread are:

1. Relationships are all about open and honest communication and trust . Keep everything visible and get any hidden feelings out into the open. Talk straight and leave your box of tricks at home.

2. There's a big difference between and estimate and a promise. Ensure that the product owner knows that the scrum team's commitment to deliver the sprint content is an estimate and not a promise. Otherwise, if the team fails to deliver the sprint content, the product owner will see the team as having broken their promise and this degrades the trust in the relationship.

3. Don't play the 'promise' game with the product owner. As Ron Jeffries says "we have better data to give them than most software organizations ever produce. Let's give them that, help them to interpret it. Let's not play a game we can't possibly win."