Probably you might agree visualizing value of a feature vs. work spent would look something likes this…
In this circumstance, it makes perfect sense to release the feature in a windows where value can be maximized:
But there is one thing missing… If we intend to scale the feature over a large population the expected return is likely an exponential curve where at a certain break point, the feature have gathered enough momentum to achieve viral spread in the crowd. If we add this curve on top of the others;
We now see that releasing the feature according to our normal cadence will short circuit our economic payoff and minimize our return.
With this in mind, I advocate for not treating all your features the same. Many will make use from being part of a regular release cycle, but if we are interested in maximizing our economic return, not all.
3 responses on “Early release is not same as maximizing your return”
Sometimes we release early anyway. If a feature takes two sprints to complete, you can still get some value after the first sprint.
The trick is to split the user story into two pieces and bring the other half to the next sprint. Sometimes this is harder than you might think, because it feels almost like a defeat not being able to finish a user story within one sprint.
There can be several reasons for releasing in parts, one valid one is to see if/how our solution works.
If we recognize the that there are different releases, (learning releases and market releases) we can better learn how to treat our features. Mistaking a learning release from a market release can quickly erode our users trust.
Very nice post! I’ve translated it into french :
Livrer tôt est différent de maximiser le retour sur investissement