The conventional agile wisdom* is that a product backlog should be strictly ordered in terms of business value. There are many good reasons for this that are well documented elsewhere and for the overwhelming majority of cases this maxim holds true. It is certainly an ideal that all good Customers and organisations should be striving for.
But it is not the only strategy and in some circumstances there are alternatives that may be more suitable or at the very least worth some examination. I would like to present one such alternative. It may be relevant to you and it is one I have used successfully; you should only consider this to be anecdotal evidence. As usual my thoughts are directed toward larger organisations where greater complexity often demands greater flexibility in approach but this may be helpful to the smaller team also.
The strategy involves not prioritising the most valuable stories first.
Firstly, as with any strategy, conditions, terrain and the skill of the troops are important in deciding whether it is appropriate. Consider whether the situation you face is similar to this:
- You are building a new product (or very radically changing and existing one).
- The product and project are likely to be sizeable and involve a reasonably large wider team.
- The product represents significant investment by your organisation.
- There are some very specific objective and goals i.e. this isn’t a purely speculative or research-driven project
- There are fairly hard deadlines and dates involved.
- Your organisation is only average (or worse) in its ability to estimate and its ability to meet deadlines.
Lets assume that there’s already been some concept stage, some initial user testing, business case analysis and so forth i.e. you don’t have a completely blank sheet; you understand your key product drivers.
Lets also assume that, as the Customer, Product Owner or Product Manager you have already done some initial analysis on your backlog and you have a list of only those things that are either Important and Urgent or Important and Not Urgent.**
The question now becomes, how best to order the Important and Urgent items. The common strategy would be to attempt to place them in order of business value, or customer perceived value, or possibly ROI if the latter differs. By all means do that now. Make a first attempt. You may decide ultimately to return to this approach and even if not it will make an interesting contrast to the approach I will outline.
What I am now going to suggest is that, of the stories and features we currently know about, we will order them with the least business value first. Only when we have prioritised the items of lowest value will we add the important stuff.
Let me explain first how, and then why.
What we are going to do is classify our Important and Urgent stories into two categories. Value Generating and Non Value But Necessary (NVBN).
The Value Generating category should be pretty easy to start populating. These are the stories that are going to make the money, please the customers and be at the heart of your offering. The NVBN category is a bit trickier (incidentally, if after this exercise you have stories that fit neither then you can almost certainly throw them away).
An NVBN story is one which is absolutely critical to the product in that things just won’t work without it, but it is also one that does not represent revenue or real value to your customer. You might prefer the term hygiene factor. Be careful, these can be hard to identify correctly. Let me offer a few examples.
Assume we are building a new website that will help users download Widgets. These Widgets come in a variety of formats and prices. Our main objective is to offer low cost, high performance purchase and delivery of Widgets.
Lets take a couple of obvious Value Generating stories.
‘Download a Widget in a short time, ideally less than 30 seconds on a normal broadband connection’
‘As a user if I supply an accurate catalogue reference then take me directly to the Widget so I can start the download’
These are simple. They are obviously the core proposition and they are primary reasons why our customers will use our site.
Here’s a couple of pretty obvious NVBNs.
‘Display a page containing the Terms and Conditions.’
‘As a user who has forgotten their password, email me a reminder to my registered email address.’
These are also pretty simple. The first is a legal requirement. We cannot avoid doing it even though, frankly, we suspect that hardly anyone will read it. Unfortunately its the law. We can’t launch without it.
The second is also pretty straight forward. We know users will need password protected accounts. We know people will forget their passwords. We can’t afford to lose customers who can’t log in so we must provide a mechanism for either resetting passwords or reminding them. Notice we haven’t specified how (because we’re pretty good at writing stories), just that there is a need that must be fulfilled. It is a necessary feature but it is not a value-oriented activity. The quality or otherwise of our password reminder service is unlikely to drive away customers, nor will it generate any real revenue.
(It has been suggested to me that any feature can be considered as Value Generating if done well enough. That is to say that the total experience is greater than the sum of its parts. I agree. However unless you’re lucky enough to be Google then I assume you don’t have the luxury of open ended projects or inexhaustible budgets. So we’ll leave this philosophical view to one side)
Now lets look at a trickier feature. I’ve wrapped this as as single story but in the real world this would probably represent several individual stories. Its an Epic, if you like that sort of thing.
‘As a new user visiting the site I want to register for the service so I can download Widgets.’
Which category does this fit into? Its harder to say. At first glance it seems a good candidate for a NVBN. After all no-one visits a site purely for the thrill of registering***. It would seem to be a pure hygiene factor. But things may not be so straightforward. Registering is one of the first interactions between you and your potential customer. A poor registration experience may put off an impatient user. What about your competitors? Are you the only one in the market with a this kind of service? If not then its especially important you engage the user positively right from the start. They are not likely to abandon you because the Terms and Conditions page wasn’t a thrill-a-minute but if registration is cumbersome or in any way difficult you may well lose that potential customer. They might give up.
In short it is hard to know how to classify this one. It depends on your business model, the uniqueness of your service and many other factors. If you are in doubt then don’t make it an NVBN for reasons I’ll come onto later.
Ok, so we now have a list divided into two categories. Those that make the money, those that don’t but we can’t do without them (remember we threw anything else away).
The first part of your backlog will now contain all those NVBNs, preferably in order of least useful to most, if such a thing is possible. The remainder of the backlog will contain the value-generating stories and these should now be put into the typical business-value order. All NVBNs will thus be prioritised into the first few sprints or iterations.
The key thing to remember is that for these NVBNs you must adopt the simplest thing that could possibly work mentality. Your goal is to spend the least amount possible on these features. You must be brutal. You cannot justify any luxury on things which do not bring a return.
Here’s why.
Recall that your are developing a new product. Unlike extending an existing product there is a minimum critical mass of requirements that must be met before the product can launch. No matter how well the project fares it must address these NVBNs at some point. The classic highest-business-value-first model is designed to ensure that the best features arrive to market at the earliest opportunity, but in this case even with all Value Generators in place, you cannot go to the consumer without your NVBNs (if you think you can then they are not really NVBNs. Either decide they generate value or discard them.)
Brand new products have a greater number of unknowns and a greater degree of uncertainty. Its harder to predict the project. There will probably be some new technologies involved, possibly new team members and a new set of challenges that differ from previous projects. If this were not so then this would be manufacturing not development.
Its also true to say that despite this inherent uncertainty in product development the wider organisation will still want dates and deadlines. There are many activities with long lead times that cannot wait until near the end of the project to know when it will be ready. They will want some reasonable level of confidence and commitment to an end-date as early as possible. A classic example is TV advertising. Its very expensive and often the slots need to be booked some considerable time in advance. Organisations will very often spend a good deal more on their TV campaigns than the entire development effort of the project. For them an end date is critical. Missing it is horribly expensive.
From your viewpoint therefore you have a limited amount of time, a fixed capacity for development (a value which you cannot know with any accuracy) and estimates which by their very nature will be at their most inaccurate at the start of the project.
So, by scheduling the NVBNs first you get the following benefits.
- When they are complete you will know exactly how much time you have left for Value Generation. You will have a much clearer picture of what you have to spend, and therefore where and how much you should allocate to Value Generating stories. You have paid your non-refundable deposit and you will also have the earliest view of whether this is going to be enough.
- Your development teams will have some meaningful, on-project experience under their belts. Their estimation will be improving and so will their understanding of the objectives. Now is the time you can begin communicating out end dates or your levels of confidence in them. Other related activities can now get underway in earnest. In the past, for new product development projects I have observed that a team tends to hit its peak performance about a third of the way in and tends to experience its lowest performance at the start and the end of the project. I can’t draw on sufficient personal data to make any scientific claim about this performance profile but if you buy the theory then it means that this prioritisation strategy has the most valuable stories coinciding, approximately, with a team’s peak performance.
- The initial stages of a project always come with a certain amount of overhead and noise from ‘setup’. This occurs as teams settle into a routine, communication is established, environments are rationalised and so on. It is much better that this noise occur during development of low value stories when the goals are simple.
- NVBN stories are not only relatively boring for the consumer they are also almost always equally boring for the development team. Getting them out of the way early means the project is growing in interest rather than waning into tedium.
- Doubtless on a project of any size there are many other specialists involved. Legal, User Experience, Graphic Design and so on. By focussing on NVBNs first you are buying them more think-time for the really important stuff. This is also true of your strategic thinking. You are in effect deferring decision making about more important stuff until the last responsible moment. A key element of Lean development. You are trying to strike an optimal balance between time-to-market and extending the knowledge acquisition phase.
Now a word of warning. In adopting this approach you are deviating somewhat from the ideal, agile approach. Therefore you should do so with caution. Be very sure that your situation warrants it. There are also some possible problems to watch out for.
You must recognise that you are taking a bit of a gamble. This is a non-refundable deposit. Its a trade-off and you need to make sure it pays. Working on higher value stories first brings with it the opportunity to fail rapidly and ‘can’ the project quickly but you are unlikely to learn a great deal from developing hygiene features. Similarly the landscape may change during the project. You need to be pretty sure your NVBNs are likely to remain relevant. In adopting this strategy you will have generated no real consumer-value in the early stages.
This leads to the important point that you must ensure that NVBNs are really NVBNs. Failure to correctly identify these as essential leads directly to waste. If you are at all unsure then they do not belong in the NVBN category.
You must ensure that all NVBNs are implemented with the lowest cost possible and with the simplest acceptable solution. You have limited resources. These must be maximised by spending the largest possible proportion on Value Generators. Sometimes the best solution for an NVBN is a simple manual procedure that you will replace later, say in a future release. If so, and the short terms costs are manageable, then choose this route.
Do not confuse early scheduling of NVBNs with scheduling for technical ease or reducing technical risk. Development teams often make very persuasive arguments for doing stories earlier, or in a particular sequence based on perceived savings; ease of testing, logical flow etc. This is not the same thing. Low value items should only go first because they are truly essential and unavoidable.
Do not confuse lower quality user experience with lower quality coding. The former is acceptable (for NVBNs) whilst the latter is dangerous. One thing you do not want to happen is for the NVBNs to become a source of serious defects or other related overheads.
Finally, its important to understand that this strategy is really about compensating for limitations elsewhere in your organisation. As you continue on your Lean journey you should be focussing on lifting such limitations rather than finding avoidance strategies. But alas, we must live in the real world.
Good Luck!
*How strange it is that the words ‘conventional’ and ‘agile’ are now so commonly found together.
** Congratulations. This is no small achievement
*** My apologies to any of you who may actually derive pleasure from this.
No comments:
Post a Comment