tag:blogger.com,1999:blog-49343788879157647412024-03-14T10:17:57.341+00:00I, CustomerAn agile resource for Customers, Product Owners, Product Managers and possibly Software Developers from a 'Poacher-Turned-Gamekeeper'Simon Joneshttp://www.blogger.com/profile/08143649591404420955noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-4934378887915764741.post-16107523769988228252009-10-20T16:34:00.001+01:002009-10-20T16:45:50.686+01:00Least-Value-First, An Alternative Way To Prioritize Your Backlog.<div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">The strategy involves <i>not</i> prioritising the most valuable stories first.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;"><br />
</div><a name='more'></a><br />
<div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">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:<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- You are building a new product (or very radically changing and existing one).<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- The product and project are likely to be sizeable and involve a reasonably large wider team.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- The product represents significant investment by your organisation.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- There are some very specific objective and goals i.e. this isn’t a purely speculative or research-driven project<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- There are fairly hard deadlines and dates involved.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- Your organisation is only average (or worse) in its ability to estimate and its ability to meet deadlines.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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 <a href="http://tcbventures.blogspot.com/2009/10/moscow-must-die.html">Important and Urgent or Important and Not Urgent</a>.**<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">What I am now going to suggest is that, of the stories and features we currently know about, we will order them with the <i>least</i> business value first. Only when we have prioritised the items of lowest value will we add the important stuff.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Let me explain first how, and then why.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">What we are going to do is classify our Important and Urgent stories into two categories. Value Generating and Non Value But Necessary (NVBN).<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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).<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Lets take a couple of obvious Value Generating stories.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">‘Download a Widget in a short time, ideally less than 30 seconds on a normal broadband connection’<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">‘As a user if I supply an accurate catalogue reference then take me directly to the Widget so I can start the download’<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">These are simple. They are obviously the core proposition and they are primary reasons why our customers will use our site.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Here’s a couple of pretty obvious NVBNs.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">‘Display a page containing the Terms and Conditions.’<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">‘As a user who has forgotten their password, email me a reminder to my registered email address.’<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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 <i>how</i> (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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">(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)<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">‘As a new user visiting the site I want to register for the service so I can download Widgets.’<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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).<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">The key thing to remember is that for these NVBNs you must adopt the <i>simplest thing that could possibly work</i> 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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Here’s why.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Recall that your are developing a <i>new</i> 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 <i>at some point</i>. 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.)<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">So, by scheduling the NVBNs first you get the following benefits.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- When they are complete you will know <i>exactly</i> 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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- 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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- The initial stages of a project <i>always</i> 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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- 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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- 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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">You <i>must</i> 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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">This leads to the important point that you <i>must</i> ensure that NVBNs are <i>really</i> 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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">You <i>must</i> ensure that all NVBNs are implemented with the lowest cost possible and with the simplest acceptable solution. You have limited resources. These <i>must</i> 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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">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.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Good Luck!<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 10.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">*How strange it is that the words ‘conventional’ and ‘agile’ are now so commonly found together.<br />
</div><div style="font: 10.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">** Congratulations. This is no small achievement<br />
</div><div style="font: 10.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">*** My apologies to any of you who may actually derive pleasure from this.<br />
</div>Simon Joneshttp://www.blogger.com/profile/08143649591404420955noreply@blogger.com0tag:blogger.com,1999:blog-4934378887915764741.post-45036791835208649732009-10-18T16:53:00.003+01:002009-10-19T09:50:58.545+01:00MoSCoW Must Die<div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">The MoSCoW method for prioritising requirements or stories is both flawed and unsuitable for truly agile projects. I have seen many man hours burned attempting to categorise stories in this fashion by people, who frankly, should know better (including me). Do yourself a favour and steer well clear.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">There’s a reasonable summary here: <a href="http://en.wikipedia.org/wiki/MoSCoW_Method">http://en.wikipedia.org/wiki/MoSCoW_Method</a><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">If your business is in any way typical of most organisations then the characteristic you will share with everyone is that there is always more to do than the available time allows. No organisation, no matter how large, can do everything it would like to do. In fact it is more serious than that. No organisation will have the time to do all the things it considers to be absolutely essential.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">And here’s why.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><a name='more'></a><br />
<br />
<div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">You cannot rob Peter to pay Paul. Your current project will not be the last project. In fact, conceptually speaking any organisation is always engaged in one giant, never-ending project. In your current ‘project’, any time you spend on anything that is not absolutely critical is time you steal from the next project. Time, at least for the moment, cannot be altered and cannot be reclaimed. In the theoretical lifetime of you organisation there is only a finite number of days. You cannot get a wasted day back.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">And this is why MoSCoW is meaningless. A Could Have, by definition, must never be implemented at the expense of a Should Have. A Should Have should never be implemented at the expense of a Must Have. Taking this to its logical conclusion means that you can never implement anything that is not a Must Have until all the possible (known and unknown) Must Haves have been completed.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Will the next project contain Must Have requirements? Yes, of course it will, therefore logically when you complete all the Must Haves in the current project you should immediately move to implement the Must Haves for the next as, by definition, they are more important than anything else.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">As a side note this is one reason why many organisations find themselves in the situation where ‘everything is a Must Have’. Sponsors of stories or requirements quickly learn that any category other than Must Have will almost certainly consign their requirement to the dustbin despite the reassurances from Product Management. Therefore everyone games the system, creating elaborate and often spurious justifications as to why their particular requirement is essential.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">So, MoSCow makes no sense, creates conflicts of interest and is also a time consuming activity with very little benefit.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;"><b>The Alternative to MoSCoW.</b><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">I suggest you use only two classifications of story or requirement.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Important and Urgent.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Important and Not Urgent.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Everything else can be discarded immediately. There is no benefit in a third category. It is important that you communicate clearly to the wider business the real state of requirements. A third category (a Could Have, if you will) simply serves to give off the false impression that you intend to do something about it and as I’ve just explained, you will not.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Obviously both types of requirement, to be considered important, have been judged to be essential in that they are either profitable or non-profitable-but-necessary. But they differ in the following ways.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Important and Urgent requirements are those that have some form of time dependency i.e. they must exist by a fixed date. This date could be a variety of things. For example:<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- An external dependency i.e. some other activity cannot start until this requirement is implemented<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- A deadline for contractual reasons i.e. this feature must exist to meet some legal agreement<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- Opportunity cost. The feature must exist before a competitor is expected to deliver something similar<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- Marketing dates i.e. a feature must be delivered before a major marketing period such as Christmas or Chinese New Year.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">- The next round of user testing i.e. you want the feature available for testing at the next organised session.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">The list is possibly endless.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Important and Not Urgent are requirements with no hard deadline other than the desire to get them in the hands of customers at the earliest opportunity.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Important and Urgent requirements must <i>always </i> be delivered before Important and Not Urgent.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Important and Urgent must be delivered in order of <i>earliest date required</i>.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Beyond those rules the order of delivery should be determined by value to the customer (and therefore value to your business). Ideally each should be released to the consumer as soon as they are complete or once there are a sufficient critical mass of requirements to justify the expense of a release. Remember that software that is not in the hands of the customer is the same as software that does not exist. It cannot start to pay for itself until it is released. This point is one I find most often overlooked by large organisations.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Note that the presence of time in this classification implies that all Important and Not Urgent requirements must become Important And Urgent before they are implemented. Remember the assumption I posited earlier. The demand for features is endless.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">So, lets summarise.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">You will have a steady influx of requested for new features.<br />
<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">For each new feature you will decide whether it is important, i.e. is it a Must Have in MoSCow parlance. This is the most difficult step. You must be brutal. Either this feature has a very strong case or it should be rejected. Often this can boil down to a decision from some Demi-God on the management team. That’s fine. Sometimes this is the best way to prioritise.<br />
<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">If its not ‘Must Have’ you will throw it away (literally; don’t even keep a copy) and inform the sponsor that this requirement will not be implemented. Don’t forget to explain why.<br />
<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">If it is you will identify a dependent date i.e. when <i>must</i> it be delivered by.<br />
<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">If you can then its Important and Urgent and will go on you backlog before any other item which has a later required date and after any item with an earlier required date.<br />
<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">If you can’t yet identify a date then it goes on your backlog, at the bottom, until you can.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Now republish your backlog with its projections of what will be available and when. If things don’t stack up then don’t worry. You are the Product Owner, its not your job to figure this stuff out. You have ensured that the backlog contains no ambiguity and everything is in the correct order. Let the Project Managers and the Management Team sweat this one out. They are either going to have to spend more money or revisit their business cases. You have provided the TRUTH and <i>facts is facts</i>.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">This scheme is virtually foolproof, extremely simple, generates the least project risk, communicates the truth and minimises waste.<br />
<br />
If you're using MoSCow, ditch it. If you're not then please, please under no circumstances be tempted.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Good Luck!<br />
</div>Simon Joneshttp://www.blogger.com/profile/08143649591404420955noreply@blogger.com0tag:blogger.com,1999:blog-4934378887915764741.post-5252939246168742482009-10-16T12:46:00.000+01:002009-10-16T12:46:14.354+01:00The ABC of Stories<div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;">Originally posted some years ago, republished and updated here because...<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">IT STILL DRIVES ME CRAZY!<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">One of the essential tools in the Customer’s armoury is the Story. Its a simple, easy and effective little tool. My four year old nephew could write them. So why is there so much material written about it? Why the endless blogs (guilty) and tedious articles on how to write them? I’ve even seen whole books devoted to the subject!<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Fortunately, after nearly ten years of writing them, using them and most satisfyingly, tearing them up I can safely say that I know a thing or two about Stories. So, here is what I consider to be the essentials of writing good Stories. You don’t need to know anything else. (note: this is just about writing the story itself. I don’t discuss prioritisation, planning, releases or any other such horrors)<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">It helps to remind ourselves of what the <i>purpose</i> of a Story is. This will greatly demystify their production.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;"><br />
</div><a name='more'></a><br />
<br />
<div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">A story is a tool for product planning, its is an aide memoire for a small item that may eventually be part of the product. Its a little something that will jog your memory and remind you what needs to be done and approximately when.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">That’s it.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Really. That’s it.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Its no more advanced or intricate than a post-it note and requires about the same level of thought. I’m sure you often use post-it notes and I’m equally sure you take very little time to think about their contents and in fact you probably just write what is obvious and minimal.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Here’s an example of a post-it note I wrote yesterday.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">‘Pick up some cheese.’<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Here’s an example of a story I wrote for an advanced product catalogue application a few years ago.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">‘Display the non-VAT price.’<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Spot the difference? No? I’m not surprised because there is none. One is reminding me to get some cheese (I have an addiction to cheese-on-toast) the other is reminding me to display the non-VAT price on the user interface of my product catalogue application.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Both of these took me about the same amount of think-time and approximately the same time to write. One I wrote on a piece of sticky yellow paper, the other in a row in a spreadsheet (can you guess which one is which?).<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">So, as I have just amply demonstrated, if you can write a post-it note for the shopping you can write Stories for an agile project.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">You may ask:<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">‘But what makes a <i>good</i> story SJ?’<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">In fact, the two examples I have given have remarkably similar properties and are pretty solid examples of exactly what makes a good story.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">They are mercifully short.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">They tell me enough but with no details or specifics.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">They could go in a list along with other Stories/Post-Its.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">They would each be relatively small tasks.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">My mother could understand them.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Lets look at each property in turn.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">1) Good stories are mercifully short.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Thank goodness! Of all the things that a Customer or Product Owner has to do, by far the least important is paperwork. The shorter the story the less you have to think about it, the less you have to write and the less anyone else has to read.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">2) Good stories tell me enough without any details.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Lets look at my cheese example. When I read this note tomorrow I will know exactly what I want and what I need to do. But, it is missing all sorts of information; what type of cheese, how much cheese, what brand, which shop. If I am very worried about my memory and if it is critically important, I might decide to amend my note to say:<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">‘Pick up some Cheddar cheese.’<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">But as Cheddar is my preferred weapon of choice when it comes to toasted cheese I think its unlikely I’ll forget.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">And this is the essence of Stories. They are a tool for YOU. You the Customer. They are not for developers, they are not test specifications or design documents, they are certainly not for management presentations. They are for you and you alone and therefore should contain only what <b>you</b> need.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">3) Good stories can go in a list. i.e. you can prioritise them.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">In particular they should be items that can be ordered arbitrarily. Don’t think about this one. Anything can be ordered arbitrarily despite what your Architect or Project Manager might tell you. Its not your job to worry about how this is done. Just put them in the order of priority that makes sense to you.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">4) A good story is a short task.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">In my cheese example (assuming I am only going to get this one item), I can figure thats its going to take me a couple of hours. Travel to the shop, item selection, the dreary supermarket checkout, paying for the parking and home again. I’ve done it before and I can be reasonably confident of the two hour estimate.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Take the VAT example. As a Customer I’ve asked for stories like this before, so, using Yesterday’s Weather I can probably hazard a reasonable guess this will take the team a day or two. I’ll probably run it past them first, just to make sure there’s no elephant in the room, but most likely, its a pretty small task. If the team estimate wrong on something this small then how far wrong can they be? Even an inaccuracy of 100% is only going to be a day or two more.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">The main reason for the size quality is that its pretty easy to work out the size of something small. So, as long as we keep the stories pretty small we can be fairly confident of the estimates provided. You’re setting up your developers to succeed.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Hang on though.. what if my story is too big, you say? Well, here’s the rocket science bit... tear it up and write two or more stories that are smaller but together do the same thing. I apologies for the complexity involved here, I promise the rest of this blog will be much simpler. :)<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">5) A good story is simple enough that my mother can understand it.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">This is probably the most important criteria. Anything more complex probably contains too much detail (very bad) or is poorly understood by the author (even worse). You are likely to be discussing Stories and the product overall with a wide diversity of people very few of whom will either care or be able to understand the underlying detail. Keep ‘em simple.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Another element to this is the idea of story ‘fixation’. This phenomenon occurs when the Customer puts too much detail on a story too early. There is some property of the written word that creates in the minds of the readers something contractual, something binding. They ‘fix’ on the detail and then you find yourself in difficulties later as you try to explain that you’ve changed your mind.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">The story should only express the ‘what’ or the ‘goal’. Avoid any references to the ‘how’ in the story. Here’s two examples.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">‘Each time a user logs in remind them of their remaining balance.’<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">‘Each time a user logs in remind them of their remaining balance in the top left navigation bar.’<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">The first specifics the goal, the second is beginning to wander into the how. There are many ways we could tell the user and this detail is best left to the process of development.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">That’s about it!<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">A story is just a placeholder, the details, whatever they may be, belong elsewhere. A child could write them, and if you happen to be developing software for children why not give that a go!<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">You have much more important work to do that agonise over Story structure.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Some questions you might have:<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Q) But what about all the other stuff, estimates, actuals, priorities, details, acceptance tests etc.?<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">A) Don’t even worry about this stuff whilst creating stories. This is Meta-Data about the stories and will be applied later. You might want to know some of this info, but I’d leave it to your Project Managers or Scrummasters who enjoy this nonsense much more than you do.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Q) What about numbering stories?<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">A) My advice is don’t do it. There is no benefit in it for you at all. The problem with numbers is other people will use them as a key or index. This is fine until you scrap a story and write some new ones. What index will they use then? Do you want to maintain indirect indices, story lifecycle histories etc.? No, of course you don’t. Don’t be tempted to use stories as some kind of categorisation system for the whole project. I’ve done it and I would never recommend it to anyone.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Q) What about using the ‘As a User...’ story style?<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">A) If it works for you fine. I use it occasionally as it tends to remind me to keep out the ‘how’ and focus on the ‘what’. Just don’t be a slave to it. Most of the time a simple ‘<i>display the time</i>’ style will do.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Q) What should I use to capture my stories?<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">A) I like post-it notes, cards, fag packets; whatever comes to hand. Longer term you probably want to use either a spreadsheet (pretty popular with management types) or perhaps a wiki. Personally I think that Mind Maps make a create story repository and have many other benefits besides. There’s plenty of good software out there, free and commercial. What I would resist strongly is the use of any of the currently available agile planning tools. Don’t get suckered into it. Let project managers figure out what tools they want to use. You are the Customer and project planning ain’t your job! Once one of these tools creeps in you’ll find yourself pulled into a world of statistical pain, illusory projections, resource scheduling and all the other horrors of naive project management.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">If I’m working in a very politically-oriented company then I may even be so mischievous as to avoid publishing all stories. I am the Customer. I decide what gets done and when and as I am able to change my mind frequently (and I will) then publishing six months worth of stories up front is just noise. Don’t do it.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Q) What about Theme’s, Epics and so forth?<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">A) Don’t waste your time. They don’t add any value. A Theme is pretty much just your management team’s high level goals. Don’t bother trying to link stories to them. Most won’t fit well anyway. As for Epics they are simply big stories. You’ll break them down when you need to and <i>throw the original away. </i>If you must call them Epics then fine. Just dispense with them as soon as you have replacement stories.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Q) But my developers are complaining there’s not enough detail to estimate?<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">A) You, and they, are missing the point. The detail required must exist somewhere, in documents, presentations, in you head. But it doesn’t belong in the story.<br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 16.0px;"><br />
</div><div style="font: 13.0px 'Times New Roman'; margin: 0.0px 0.0px 0.0px 0.0px;">Trust me when I tell you that you can manage a huge project on nothing more than a board full of post-it notes. I’ve done it several times and on very large projects. In fact the somewhat counter intuitive notion to remember is that the larger the project the <i>less </i>complex your system should be.<br />
</div><div><span style="font-family: 'Times New Roman'; font-size: small;"><span class="Apple-style-span" style="font-size: 13px;"><br />
</span></span></div>Simon Joneshttp://www.blogger.com/profile/08143649591404420955noreply@blogger.com1tag:blogger.com,1999:blog-4934378887915764741.post-92182281389805947392009-10-15T17:00:00.003+01:002009-10-15T18:39:01.709+01:0080% of drivers think they are better than average.<div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">The idea of the Superiority Bias is not a new one and yet I find that it permeates software development to such an extent that it is alarming.<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">The quote that makes up the title of this blog is from a now famous study conducted by McCormick et al in 1986* which tested a number of drivers on eight different aspects of their driving ability. <br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">The outcome was that <b>80%</b> rated themselves as <b>above average</b>.<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">This Superiority-Bias, that we often assess ourselves to be better than we actually are, has some fairly profound implications for software and product development. It is also something the shrewd Customer should be aware of.<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
</div><a name='more'></a><br />
<br />
<div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">In my own experience in the many years I have worked in software development I have found very few programmers who actually believe they are below average. Despite the sometime staggering defect rates I’ve observed, the rank-amateur coding practices, the rampant duplication (the biggest of all programming sins) and the endless technology debates, all based on nothing more than fashion, the vast majority of programmers think they are ‘better than the norm’. <br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">(Incidentally, I consider myself a significantly above average developer).<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">So, what are the possible implications for we, the Customer, in the face of the Superiority Bias?<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">Unless, like me, your are fortunate enough to come from a development background and are already painfully aware of this bias in everything you do, there is a good chance you will have to rely on the developers themselves (or worse still the architects and line managers) to tell you whether you have a quality product or not i.e. if the code is simple, maintainable, logical, free of duplication. Yes, the stories are delivered, the acceptance criteria pass and your test-users have liked the end result, but, will you have a maintenance problem and be faced with decreasing ROI in the months to come?<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">According to the Superiority Bias you can’t ask the people who wrote the code (or were closely involved) because they will naturally over-estimate the quality of their own work. And with something as complex as software its difficult to know the scale and effect of the bias.<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">So, whatyagonnado?<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">Firstly you’ll have to accept that not only will this bias inevitably exist (and you won’t be able to eradicate it) but also that software development itself is not a mature science or anything approximating it. There are no hard and fast rules about what makes good or bad code and if there were they would surely be highly sensitive to context. Even such guidance as there is can still cause endless, heated debates between developers themselves.<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">You can’t solve this but <b>knowing</b> is half the battle. Now you are aware you can adjust your expectations accordingly. So, unless your company is some sort of Mecca for devout developers of the highest order then it is a good idea to adopt the working assumption that you are <b>definitely</b> being delivered sub-standard code. The estimates you are being given are estimates to deliver the <b>mediocre</b>.<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">Secondly, you need to communicate to everyone that you are fully aware of the implications of Superiority Bias. You <b>expect</b> that the code is likely to be sub-standard and therefore that you need everyone on your delivery team to be harsh self-critics. As a Customer you will always be sceptical. Make sure everyone understand that this is part of your role.<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">Thirdly, try to make criticism a positive activity and reward accordingly. In fact reserve time in your backlog for this activity. At the end of a session, perhaps each day, each development team or pair should be asked to select a piece of code (randomly is best) and find something wrong with it. Accordingly you will then ensure that time is allocated to improving it. The key here is to only criticise code produced by the critics themselves. Never allow this to be one person criticising someone else’s work. What you hope to achieve here is an atmosphere of doubt. Yes, that’s right. You want to make your developers doubt everything they do. Make it clear that such critical analysis makes you happy. <b>Be</b> happy, be pleased. Everyone enjoys adding value and in the case of an agile delivery that should be primarily derived from pleasing the Customer.<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">And if they can’t find anything wrong? Well, then at least you know you have a pretty serious problem.<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px;">By the way, are you an above average Customer?<br />
</div><div style="font: 13.0px 'American Typewriter'; margin: 0.0px 0.0px 0.0px 0.0px; min-height: 15.0px;"><br />
<br />
</div><div style="font: 11.0px Helvetica; margin: 0.0px 0.0px 0.0px 0.0px;"><span style="font: normal normal normal 13px/normal 'American Typewriter';">*</span>McCormick, Iain A.; Frank H. Walkey, Dianne E. Green (1986). "Comparative perceptions of driver ability— A confirmation and expansion". <i>Accident Analysis & Prevention</i> <b>18</b> (3, June 1986): 205–208. <a href="http://en.wikipedia.org/wiki/Digital_object_identifier"><span style="color: #1d2bb8;">doi</span></a>:<a href="http://dx.doi.org/10.1016%2F0001-4575%2886%2990004-7"><span style="color: #3466bb;">10.1016/0001-4575(86)90004-7</span></a>.<br />
</div>Simon Joneshttp://www.blogger.com/profile/08143649591404420955noreply@blogger.com0tag:blogger.com,1999:blog-4934378887915764741.post-10749542409516444722009-10-15T12:19:00.002+01:002009-10-15T12:23:22.333+01:00Our New BlogHello All,<div><br /></div><div>We have decided to migrate our articles, blogs and posts to this new location. At the same time its a great way to do a little housekeeping; delete the irrelevant, update the aged.</div><div><br /></div><div>So, over the coming months some of our old material will reappear in a new and invigorated form. Some of the chaff will be cut.</div><div><br /></div><div>And of course there will be plenty of new food for thought.</div>Simon Joneshttp://www.blogger.com/profile/08143649591404420955noreply@blogger.com0