The "Funnel" Prioritization Technique

I've been developing a website called Flyc for about a year or so, mainly in my spare time. Flyc stands for 'For Launching your Career' and is aimed at helping job seekers track their jobs online.

Yesterday while working on the site's user stories and schematics, I hit a road block. It was mainly psychological at first, but then after re-thinking my approach I noticed that I was just overwhelmed with the amount of 'stuff' I was planning on achieving in a short timeframe.

So I started thinking about how do I go about prioritizing my work. I was mainly thinking about the 'scope' I wanted to define for the 2nd release of the recruitment site. So I defined 70-odd user stories which match needs I gathered from potential users of this site.

Now I could have used 2 familiar techniques to prioritize the User Stories:
1. Use the 100-500 Business Value technique
2. Prioritize by sorting them (user stories at the top are more important and user stories at the bottom are less important)

Both techniques are good. While using the 100-500 business value scale on some projects in the past I found it quite hard to get a good reflection of the priorities in one go and most of the times it takes a few iterations to get to a good comfort level. I developed this approach of first 'grouping' the user stories into 5 or more groups where each covers a range of business values. E.g. The 401-500 group / range includes user stories that are really high-priority, the 301-400 group / range includes ones that are a bit lower ni priority and so on. You can also break these groups further into smaller groups if needed (i.e. 351-400, 401-450 etc).

This in fact introduces some form of a grouping mechanism which psychologically helps people prioritize and scope work to be done.

The interesting 'prioritization' bit kicks in once the project is under way and 'deadlines' are approaching. From personal experience as a developer recently, sometimes the amount of functionality desired is too much of a stretch to achieve good 'momentum' and keep the morale / motivation high.

So getting close to a date I wanted to release the first stable version of the site, I started 'culling' functionality. By doing this I was able to determine the 'bare' minimum that would yield 'acceptable' value. It worked.

So I figured, what if at the outset of a project we prioritize the work into fine grained groups which are only based on 'business value'??

So here comes the 'funnel' prioritization approach which is based on a logical and human-centric technique for distilling down to the most important bits.

1. 1st Prioritization - Divide the entire scope into groups based only on their 'business value'. Grouping could be done initially by dividing all user stories into 3 main groups: high value, medium value and low value
2. 2nd Prioritization - Put the medium and low value groups aside and divide the high value group into smaller groups
3. Continue dividing the top-most group recursively until you reach small groups of 5 user stories. The top group (should now give you a good indication of what could be the 'bare' minimum required to provide some tangible value
4. Now follow the above steps for the medium and low value groups. This will give you a fine grained grouping of value-based functionality

The interesting thing is that this approach is focused on 'value' creation and not necessarily agile / 'scrum's view of prioritization which takes into account the 'how big?' factor combined with the business value. Looking at this I think the 'business value' will determine the overall and incremental scope of a project. As more often than we know, some projects don't deliver all functionality 'desired' or the 'money' runs out. So to be able to 'always' pull the plug at the end of each release, the releases should be driven by 'business value' prioritization perhaps using the 'Funnel' technique above.

This approach is a bit different to the traditional agile / scrum approach and takes into account true 'business value' and 'pulling the plug' ability. This may introduce 'releases' / iterations that are not similar in duration. I believe this approach is more realist in most organisations where many people work on multiple projects at the same time.

This of course has big impact on software architectures and frameworks as they will have to be reasonable fluid and refactorable until such time as the scope is committed by all stakeholders (including money and time commitments).

In a nutshell, I think a 'Funnel' prioritization approach is another simple and effective way of distilling large amounts of functionality or requirements into small, value-based, manageable chunks.

What do you think?