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!
- Consistency and Innovation: Pick One
- Pair Programming - My Personal Nightmare
- The User Interface and the Halo Effect