Scope. As my friends at Good Mythical Morning say, ‘Let’s talk about that’...
There can be many ways of looking at delivering value for users (when it comes to web projects), and a typical one is dealing at the feature level. When something happens to trigger a project, usually an opportunity that’s been identified, or an issue to solve, it begins with a list of possible things that could deliver the answers.
That list gets refined down until a clear set of ‘to do’s’ are established, and you can see how that new feature would provide that value and therefore ‘problem solved!’.
But it’s not as simple as that. One feature may have many parts - each with a level of value in themselves. For example, one feature may have 10 components outlined within it, with three of these adding extremely useful stuff, another four adding more richness to these, and a final three that are less important to the overall outcome, but would be cool to have.
When faced with a feature list to estimate (as a vendor), often we have no context of this, and have to treat all 10 as equal value, and therefore estimate to deliver, test, and support all 10 as one whole. In some cases, all 10 components may be adding extremely useful stuff, but in my experience, 9/10 cases can be broken down into these three groups. People often prioritise features into ‘Must have’, ‘Should have’ and ‘Nice to have’, but again, if it’s at the feature level, it can only ever be considered in its entirety.
What works very well is to think in ‘layers’. You still have your list of features, but you map them in layers of importance/value using techniques like ‘User Story Mapping’ which lets the most valuable items rise to the top. In user story mapping, teams create a dynamic outline of a representative user’s interactions with the product, evaluate which steps have the most benefit for the user, and prioritise what should be built next.
It looks something like this:
Although I do like sticky notes, I prefer cake. So let’s look at cake instead. We are going to make a delicious delicious cake (project) and we want to be able to eat (use) it.
(The ‘release’ outlined in the story map image above)
For us to be able to eat cake, we need to still complete the full end to end process of making a cake, but it would be in it’s simplest way possible for it to be edible. Our ideal cake would be three tiers with layered icing, but once we completed our first layer, we could still eat that delicious delicious cake. Projects work like this too - after making a first pass, we could release this and have users get the benefits of this now, even though there is more to come.
Adding more cake to an already delicious delicious cake is a great idea. So we add more richness to the features and build out things that are going to make it even more valuable to them. And let’s be honest, a two tiered cake is likely all anyone will ever need. At the end of this second pass, all of the main parts will be here, and users will have reached almost the top of the bell curve of value with this.
So the third pass (layer) - this is typically where the budget gets tight, and there may not be enough left to add the full tier. But that’s okay, as the users have been eating cake for some time now, and have been really happy. This layer adds the extra richness, the bonus features, the nice to have’s. Sometimes this is where the feedback on how the other tiers tasted comes in, and you may be able to make it taste even better - change the top layer to chocolate frosting and cover the entire thing in sauce. But ultimately, you have a very grand, very rich three tiered cake to everyone agrees is the most delicious thing they have ever eaten.
My analogy may have spun off in a cake happy delirium (see image below), but the theory behind it works. It gives Product Owners and the business benefit in the right places, your costs can be relatively fixed if you have the option of not adding the third layer, and the users have their cake and get to actually eat it too!