Pop the 'Why?' Stack

You should discuss...the feature and pop the why stack max 5 times (ask why recursively) until you end up with one of the following business values:

  • Protect revenue
  • Increase revenue
  • Manage cost

If you’re about to implement a feature that doesn’t support one of those values, chances are you’re about to implement a non-valuable feature. Consider tossing it altogether or pushing it down in your backlog.

- Aslak Hellesøy, creator of Cucumber

(If you follow the link, you can also read the transcript of an IRC session in which Aslak helps someone pop the "why?" stack for a "login" feature.)

6 comments :

Anonymous said...

Great article. Generally I write financial models, so I get the easy part of the why question - but bringing the group together is a tough thing to accomplish. I appreciate the insight.

Anonymous said...

This post seems short sighted, at best.

Please clarify your definition of revenue

Anonymous said...

@Anonymous, my knee jerk reaction was "are you an idiot? Revenue is $ coming in." But you are right to draw attention. This idea could be used to justify the suggestion that features be pushed out as quickly as possible, regardless of how ugly or badly implemented they are, in order to bring in the bucks sooner. This is bound to happen in organizations where quality and craftsmanship are not shared values.

If you consider how support costs and maintenance affect long term revenue (money coming in), via qualify perception and taking into account costs required for support, then popping the why stack is a good way to avoid gold plating. Which developers and product managers, and sometimes even CEOs like to engage in.

The focus on revenue, gross revenue, is too narrow though. It should be net revenue, total profit, taking into account costs such as support and so on.

Anonymous said...

the @Anon was me. Too much effort to login via BB.

There are two points I wanted to make here.

The revised version of your statement ( IMHO ) is a lot broader and leads to a 'revenue grey area'. It's hard to decide whether features / practices can immediately or even eventually lead to an increase in net revenue.

This also discounts the possibility of innovation within a corporate setting: redesigning the current systems, upgrading to better programming tools, implementing some best practices: reviewboard, opengrok, wikis, etc

The Geisslers said...

There is another reason not included in your list -- To comply with regulations.

Websites ask if the user is over 13, not because it will increase revenues, but because they must by law (in the US).

In popping the why stack, that is as good of a reason to implement a feature as any other.

Anonymous said...

@colin

No, but if you pop the why stack again you see that you at least protect your revenue (because you may have to take the site offline for example or be subject to legal action).