Tag Archives: product development

Filling a bucket of ideas into a release

One of the things Business Analysts do is to facilitate customers in shaping their release.  You could be shaping what the next immediate release be, or indeed, planning multiple releases that span months if not years.  A good practice that we foster here at TW is to guide our customers to a direction that will best help them figure this out.

To give a counter-example, picture a chaotic release planning.  Little considerations have been placed in selecting what features were to go into the next release, except for one rule: cram as many requirements as one could possibly squeeze (all taken from good old backlog, pick from largest estimated features).  There was no collaboration or group discussion between business stake holders but a checklist being sent out via e-mail afterwards, and all manners of chaos and pain followed.  Now back to reality and into the world of product development where this counter-example is not an option – release planning is no result of a random act, as the next release could well make or break your customer’s impression of your software that could either cause them to embrace your software, or leave.

So how do you help your customer figure out which features to have in a single release?  First, let me introduce you to the bucket.

The Bucket Analogy – Your release as a bucket

Imagine for a moment that your release is a bucket.   Now, you have a few bigger stones, a few bunches of pebbles and some sand to fill this bucket up.  The size of the stones and pebbles are relative to the size of features that go into your bucket, your next release.  A bigger stone is a bigger feature with a larger estimate, a pebble a smaller feature, and then you have the bunches of sand that make up the smaller features or tweaks that you know will be great to have, such as delighters that will help make things easier, faster or less painful.

So the goal is to fill the bucket up with the most useful things… no rocket science and straightforward enough, surely?

Prioritisation Tool – How to pick and choose to fill your bucket

Here comes the nitty gritty bit.  You know your bucket is not a bottomless barrel due to budget –  be it money, people, time.  Besides, a bigger bucket would probably not help you release any quicker – that’s a different discussion – the key to this point is figuring out how many, and what stones, pebbles and sand to fill your bucket.  And oh yes, don’t forget that each feature has to give you the most value in the most efficient, timely way.

In an attempt to answer this, I want to first borrow a leaf from a different discipline, Psychology studies.

There are 2 tools to help understand the basic concepts of this idea.  The first tool is the Herzberg hygiene/ motivator theory.  Herzberg says that there are different levels of job satisfaction.  Hygiene factor – having a safe and adequate working environment to carry out work, and the motivation factor – making work enriching for the people.  Apply this to software thinking: we need to make sure that the features in a release will not take away any hygiene factors, otherwise the people who use it will grind to a complete halt and not be able to do their job.  If you had taken away some of the enrichment part, they may not be able to do things quicker or easier, provided you give them workarounds, it will not stop them from completing a certain task.

The second tool is Kano model.  This is a way of helping customers think in terms of building quality.  This tool is the most apparent when applied in product development situations.  Kano model states that product attributes can be mapped to customer satisfaction levels: Basic, Performance and Excitement.  This model can be applied to requirements.  Imagine all requirements can be grouped in the 3 categories: Basic, Performance, Excitement.  You can build quality in a product release by choosing how much to invest in the 3 categories that will make your product meet your users’ most pressing needs.

The most difficult aspect of this is to do a balancing act of judging which features are to stay, and drop which ones in the release.  Which ones we can live without for now, provided that we get it later? You as BA for sure do not have all the answers and insight in this, so this needs to be executed in a workshop or a series of workshops to get you to your goal.  It also pays to verify the assumptions with your business stakeholders and indeed the end users.  Having said that, you are there to help shape their thinking so make sure that they understand every feature they are asking for has justified reasons, financial, strategic… Or perhaps not, in other cases.  Playing devil’s advocate sometimes help, as is re-playing conversations (“Last meeting we got all the stones in place for next release and we have pebbles next”) and key movements (“So last Friday we said we would want X and Y in the next release, and not Z because performance was not a showstopper…”) as pit stops throughout the session.

Whilst we are on the topic, there is also a clarification.  Be careful this is not to be interpreted as the Must have, Should have, Could have (MoSCoW) categories that is so commonly used.  By no means basic maps onto must-have, performance to should-have, and excitement to could-have.  This is because the brutal truth is that not all releases contain all Ms, Ss and Cs – some only have Ms and Ss and Cs never make it to the next drop.  However you need to be aware that all elements of basic, performance and excitement need to be present in a particular release.

Amalgamating 2 brilliant ideas, and turning it into one concept

Herzberg’s two-factor theory teaches us that there are some feature that you just cannot live without.  Kano model tells us what impact each feature would have on that release if you had taken those away.  By first introducing the bucket analogy, a simple conceptual model to imply the need to prioritise, and then combining the 2 theories behind the logic of what to pick and choose, then instil this to your client in order to help them gain the much-needed focus and the courage to prioritise effectively.  Try it, use that in your next release planning exercise.  It’s essentially 2 ideas amalgamated into one.

In a recent project I encountered this situation head-on, and this is how they have adapted the theory into practice and I thought I might share it here as an ending note.  This is what they have done:

Requirements, in the form of stories, are first associated with an estimate and a priority defined by the customer.  In addition to this, a parity field was added.  This field had a reincarnation of Basic, Performance, Excitement terms from the Kano model (known by different names, cannot disclose sadly)…  As soon as the idea of filling a combination of them in a release bucket was presented to the client, it took off almost immediately and each requirement were tagged with this.  Basic was the cornerstones of that release, in other words the hygiene features.  It was so well received that,  each release from then on, it has to have a mix of all basic, performance as well as excitement stories, period.  Thinking back the time at the beginning of the engagement which seems like a different era altogether, when the business stakeholders were adamant that almost everything had to be in the first release(!)  Then, slowly and surely, as the project and our relationship evolved, they have learnt to embrace the theory behind stones, pebbles and sand, and gradually realise that some features could wait until a later release.