Expectations and the Endowment Effect

September 17th 2013

Managing the expectations of the customer is one of the trickiest things in software development. Imagine this scenario...

You're just a few days into a sprint. Your customer, a reasonable enough guy, identifies a new feature related to something your working on. It's small, maybe just a 3 story pointer in a 60 point sprint, but you have a good amount on your plate as it is.

Since you aim to please, however, you let the customer know that you'll give it a shot. If things are tight at the end of the sprint though, it'll need to get pulled from scope. No big deal.

Sure enough, the end of the sprint comes, and you're swamped. You can finish everything you originally committed to, but you won't have time to finish the extra feature. You let the customer know, thinking it'll be a non-issue. To your surprise though, he's actually kind of torqued. But you're delivering what you originally committed to!

What happened here? You never truly committed to the feature in the first place, it was really just a bonus. Why would the customer be upset?

At least part of the explanation comes from prospect theory, and it's something called the endowment effect. In a nutshell, the endowment effect asserts first that we hate losses more we than enjoy gains, and second that both losses and gains are calculated not absolutely, but relative to some reference point. What does all this mean? Let's look back at the example.

Initially, the business owner expects 60 story points to be delivered, and he's content with this. A few days into the sprint, when you tentatively commit to the new feature, you do indeed make him happy. To put it in numbers, say...

3 story point gain = 10 "happiness points"

At this point, however, his reference point shifts. Whereas he was initially expecting 60 story points to be delivered, his mind is now attached to 63 points.

Fast forward to the the end of the sprint. You realize you can't actually deliver the extra feature, and so you take it out of scope. You assume the customer is thinking in absolute terms - he started out expecting 60 story points to be delivered, and that's what he's getting. This is where you're wrong.

The customer at the end of the sprint is only thinking from his current reference point, which is 63 story points, and so he perceives you not completing the new feature as a 3 point loss. Further, since people dislike losses more than they like gains, that 3 point loss doesn't just "cancel out" the 3 point gain from before, but it actually looms larger. Again, in numbers, prospect theory explains that he might feel the loss like...

3 story point loss = -20 "happiness points"

In other words, because you "gave" the customer the new feature, and then took it away, he is less happy than if you never tried in the first place! Rationally speaking it doesn't seem like it should make a difference to him (+3 story points - 3 story points = 0!). Given how our cognitive apparatus perceives losses, however, it does!

This effect shows up all over. Paraphrasing an example from the famous economist Daniel Kahneman, imagine your favorite football team is in the playoffs. You'd be willing to pay $300 to go, and fortuitously you find a stranger to sell you a ticket for that much. A few days later, the game is getting a ton of hype, and you learn that tickets are going for $1,000 online. Do you sell your ticket? No! Even though you valued the getting of the ticket at $300, once you have the ticket, you value the losing of the ticket at more than $1,000. In other words, once you have something, you hate to lose it.

What does this mean for us in software development? Well, as developers we need to be conscious of our customers' inherent loss aversion, and so always be cautious when setting reference points of any kind. This is not just limited to scope issues, either. If you tell the customer, for example, that you'll be done with some task in 5 days, you've just set the reference point. Finishing in 4 days (a gain of 1 day) will make the customer happy, but not as unhappy as will finishing in 6 days (a loss of 1 day). Losses rule!

In the end, it boils down to the advice a colleague gave me on one of my first projects: "under-promise and over-deliver". With only our words, we define the expectations others will use to measure us by. Understanding loss aversion and the endowment effect, we can use this to our advantage!

Recent Posts

  1. Consistency and Innovation: Pick One
  2. Pair Programming - My Personal Nightmare
  3. The User Interface and the Halo Effect
I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (2)
September 18, 2013
I totally agree with the fact that customers get unhappy much easier than they get happy, but i believe that making the customer unhappy can be avoided with a sincere and straight-forward approach of reviewing the current project requirements and, if needed, modifying the release date so that the new feature can be implemented.
The client reviews the estimate, and if he considers that a further away release date is acceptable for the new feature he accepts the estimate and everything continues as normal.
The drawback to this approach is that the customer probably will not become happier, since the extra feature is not delivered at the initial release estimated date, but he has to wait for it.
The good part, though, is that if the estimate the customer accepted is correct, the chance that features will be left out of the release, or the release is postponed will be much, much smaller, so the customer no longer becomes unhappy.
Anyway, I also agree with the advice you're colleague gave you!
September 18, 2013
@James - Thanks for the comment! Good point, if the deadline is negotiable, pushing back the release date is a way you could accommodate the new feature without the risk of taking it on and then (maybe) later having to pull the feature out of scope. In any case, I agree that a sincere/straight-forward conversation is the best approach, regardless of how you handle the scope creep.