What is a "commitment" anyway?

I hate giving promises for things I can’t control. I can promise that I will attend a party or that I will set aside time to help you with your problem. I cannot promise that the party will be fun or that your problem will be solved. Giving promises on effort is honest, giving promises on outcomes is dishonest.

A team that commits to an estimate is promising something they cannot control. A team that is blamed for giving an estimate that is too low can easily avoid that particular mistake next time around. And given the law that work expands to fill available time, the estimate will never be too high. The result is cost spiraling up.

What if we assumed that estimates would never be particularly reliable. And if we assumed that forcing a team to commit to an estimate is unreasonable behavior? How would we act in a world where that’s true?

Let’s imagine we live in a world where the product owner cannot ask for an estimate. What can the product owner do instead?

The product owner can say “stop working on this story if you’ve spend more than 40 hours. Or if you think you will end up spending more than 40 hours.”

Such a limit can be viewed as a budget.

The product owner can make a bet on how many user stories the team will complete by looking at what they have done before. If the consequence of the betting wrong are severe, the product owner can be cautious about the number of user stories. (Bonus question: Is the team is a better or worse position to know the consequences of betting wrong?)

Such a bet can be viewed as a forecast.

The team, on the other hand can commit to working according to the agreed-upon rules. They can commit to do things in the order set by the product owner. They can commit to doing the best job they can within the time budget the product owner has allocated.

We commit to effort, not to outcomes.

Comments:

[Anders Båtstrand] - Apr 13, 2012

I do not fully get this. In the end, not so many will care about the effort. Should the Product Owner commit to the outcome, and not the team?

Everybody knows that the team is promising something they might not be able to do, I do not believe it is common for product owner to call that dishonest.

Committing to doing the best job possible sounds for me a little vague. Do you have any details on how that would happen? What is the DoD for that?

I agree, however, to the link you posted: IF you have data for similar projects, that would probably give you a better estimate anyway. I do not think, on the other hand, that it would hurt to have the team committed to roughly the same estimate.

Johannes Brodwall - Apr 13, 2012

What I’ve seen is the stronger the team is held to their estimates, the more they pad their estimates. And with any estimates, the work always expand to exceed it. This blogpost is an attempt to break the cycle.

Johannes Brodwall - Apr 13, 2012

What I’ve seen is the stronger the team is held to their estimates, the more they pad their estimates. And with any estimates, the work always expand to exceed it.

This blogpost is an attempt to break the cycle.

Johannes Brodwall - Mar 22, 2012

The point is that the product owner is better suited to make the budget estimate. Another metaphor: If you ask for a bottle of wine to go with steak at a decent wine store, the clerk’s first response would be “what’s your budget?”

[Renee] - Mar 22, 2012

I think we might just agree to disagree here. I am not saying an “appitite” from the business is not worthwhile, but they may have an appitite of 50k for a feature based upon the value of the outcome but the estimate might be 10k. What you are saying is that we plan for 50k. The customer then misses out on 40k being planned.

I agree that you should plan for success and that at best estimates are really guestimates based upon what you know. From what you are describing you are recommending changing process to hide two problems - 1) you are not in a safe to fail environment. 2) your customer isn’t really part of your team - there is no trust or acceptance when unplanned events happen.

Johannes Brodwall - Mar 22, 2012

I’ve seen tasks that are trivial to estimate and tasks that are practically pure speculation. In either case, e.g. planning poker is irrelevant.

Secondly, when estimating an unclear story, the information that’s most useful for me to make it clear is what “quality” the product owner is expecting.

The Agile Revolution - Mar 22, 2012

Budget tolerance or threshold estimate. It still doesn’t replace a necessitation to estimate.

Johannes Brodwall - Mar 25, 2012

As often before, Jason Yip expresses the same idea more concise and clearer than me:  http://jchyip.blogspot.com/2012/03/do-you-really-need-to-ask-how-long.html (“Do you really need to ask how long a project will take?”)

Johannes Brodwall - Mar 23, 2012

I think I might agree with you more than you think, Renee.

You’re pretty right about the context, and another important thing about the context: The customer’s appetite is never sated.

In a context where the customer appetite is less than we have, my approach makes little sense.

[Trond Wingård] - Mar 21, 2012

You’re onto something, but it’s based on a (very, very common) misconception of what an estimate is. An estimate is not a point, it’s a probability distribution. An estimate is not a commitment, it’s an analysis.

E.g. an estimate is not “We can do it in 2371 hours”. It could be “Based on our analysis, this entire scope could be finished in between 1200 and 4800 hours. You want 80% confidence? That’s at 3100 hours.“ 

The discussion would then be what confidence level the project owner is comfortable with, which would then be a budget for the project. And, of course, it would make sense in the project to prioritize so that the most important stuff is delivered first.

The Agile Revolution - Mar 22, 2012

I agree that the standard commitment in Agile is to effort, but it isn’t only that. Generally you are committing to a velocity. That velocity is based upon what you achieved last iteration. If all stories are estimated in relativity to each other then the commitment should be achievable. 

So when does it not work out?  1) When change is introduced inside of the iteration. This should not happen if you are taking your sacred timebox seriously.

  1. When the conversation for the story has meant a great mis-match to the planning discussions. Good iteration planning sessions will mitigate a majority of this risk, but this anomoly will rarely happen and consequently the velocity will take a hit. Will the product owner/sme be aware of this prior to the iteration - yes! After all they were there for the conversation.

  2. When reality kicks in, ie people are sick. You cannot predict illness, but in this instance you aren’t wasting effort either way. This is probably the best example of commitment being better suited to effort rather than outcome.

But the decision that a customer is making, even if it is based upon effort commitment, is a two fold one - given the effort is it really worth it - ie is the cost to value ratio worthwhile. Given this, outcome is equally important. 

To use your own example (turned into coffee because I don’t drink alcohol) - would I personally pay for a Nescafe Blend 43 coffee even if it only costs me 2c compared to a Barista created coffee that costs $5 where I know the quality of the beans, the Barista’s skills, the milk and the machine that they are using?

I would pay for the $5 coffee everytime. Because I know of the value wrt my satisfaction levels on my taste buds. 

If the point is at what cost would I not pay for the barista quality coffee then there certainly is a threshold but that threshold was already determined in the iteration planning meeting when I knew that this story was x number of points. 

A committment to a story without considering value or outcomes is worthless.Â

[Simen] - Mar 21, 2012

I had another take on this in an old blog post of mine. In brief, you can have an estimate (your best guess), a goal (to challenge your creativity) and a budget (so that you don’t have to go ask for more if you go a little over the estimate). 

Here’s the blog, in Norwegian only: http://blog.iterate.no/2010/01/04/mal-budsjett-eller-estimat/Â

Kjersti BB - Mar 20, 2012

Thanks, this was clarifying! 

As to betting to create forecasts, have you considered using prediction market tools to enable that process? http://javazone.no/incogito/session/Prediction+Markets+-+A+different+approach+to+software+cost+estimation.html