Agile Priorities
Last Updated: 2018-12-31I am always learning more about effective software delivery and I often watch the videos by Gary Strahan on his 'Development That Pays' channel. When a video popped up on my feed entitled 'From Scrum to Scrumban in 6 steps', I dived in with a mix of inquisitiveness (what is this scrumban thing?) and scepticism (not another agile derivative!). However my inquisitiveness won the day as he went through the 6 steps to transform your scrum-type process.
On Estimating
In the past I have been somewhat obsessed with estimating for many reasons. For one, I still notice that many software developers are often so focussed on the excitement of solving a problem, that they will report in the stand-up meeting that their task is 'nearly done' for several days in a row.
I have also convinced myself that anything that is measurable and quantifiable can surely be predicted. However, having delivered several small and large scale software projects, the pessimistic side of me also tends to say 'Software is just too complex - good estimates can't be done'. Then the optimisitic side of me counters with 'yes it can! You are probably just expecting too much and measuring the wrong things'.
Stop!
So imagine my horror when point #5 of Gary's 6-step process was 'Stop Estimating'! What? But how will we schedule the work? How will we budget for it? How will we plan and coordinate launch dates?
But then I thought back to the lessons I have learned over lean processes, startups, MVPs and delivering core value of software. Are these ideologies somewhat in opposition with estimation and planning? What is more important?
The core focus
I do think estimation is important. Why? It is important for those in control of budgets; every business owner will want to know what something will cost and when it will be done. But if we ask 'why' again, the logical answer we are led to is that a business intends to make money from a product or service, and therefore the owner needs to know that the product or service provided will be able to make money before the company's investment is exhausted.
And here lies the core concept. Applying lean thinking to the question 'when will the product be done so that we can make some money?' transforms it into 'how soon can the product be useful to customers so that they will pay for it?'. And this then looks like an MVP.
What does this mean for the estimate v priorities argument? Determining the features of an MVP is all about priorities. Being fast to market is achieved by deciding what features have the most value and what have the least in order to provide value to your customers - i.e. something they will pay for. I suggest this is more important than trying to understand how long it will take to deliver. Estimation still has value, and the company's budget should not be dismissed, but if you are delivering the WRONG features then your budget will also take a big hit. And coincidentally this ties in nicely with point 4 of Gary's video: Start ordering.
Better Prioritising
So how to prioritise? When it comes to prioritising I usually think about three things:
- What features deliver core value
- What additional features do you need in order to enable those features
- Which features have are the highest risks or carry some auxilliary benefits?
Firstly, as we have already discussed, customer value is very important. If you don't provide customers with value then someone else will. Identifying values should be at the top of your list.
Secondly, those features will often have other dependent tasks or features: systems will need accounts and logins, notifications will need account profiles or settings, data reporting needs to have data collection. These tasks will need to be done first, but can sometimes be wrapped up in another feature that provides value. For example if you are building a cat-cuteness ranking application, there may be value in building a ranking per-user before a more complex site-wide system.
Lastly, don't discount any measurable risk or collateral benefit. If two features are of equal value (however you measure that), I would usually tackle the one with the highest additional benefit first, as futher valuable features may be able to be delivered faster. Beyond that, I also generally try to address the highest-risk items earlier than lowest risk, mainly because as a project marches on those high-risk or high-uncertainty items tend to have a bigger schedule impact the longer they are left.
Stop (mostly)
So in summary, I don't think you can 'Stop Estimating' in all cases - estimates still have use in the right context, especially if budget is tight. But otherwise, quantifying and ranking the priorities of your features rather than continuing with a next-cab-off-the-rank system will deliver more value to the customer, faster.