When it comes to prioritising the product backlog it can be a challenge to order the items based on what is most urgent and important because these attributes are not measurable. Urgent and important are emotional factors based on opinions that are not all created equal, it can often be led by the loudest voice in the room despite volume not being a historically good indicator of ROI.
When defining product backlog items there should always be a measurable against the proposed work, if it doesn’t have a number it cannot be measured. Product backlog items without a value proposition can exist in the product backlog but should never be positioned higher in priority than a deliverable that has a defined number value that will come from the delivered work. When there is an idea without supporting data I recommend storing such an item in an “Icebox”, a list designed to understudy the product backlog until such time that a given item gains a value proposition to be promoted to the product backlog ready for development.
This is where Data Science delivers value and prevents waste, the organisation knows it has a problem and data can help define where that problem lies and what value a given change could be expected to deliver.
I like to refer to the next stage as Data Driven Development.
With the backing of data analysed to understand a problem and propose a desired outcome, the development team are handed more concise direction to deliver a potentially shippable product come demo day. This approach to delivery allows all parties to know and understand what a development team is doing and why they are doing it at all, along with why they are doing it first.
Prioritising an item that will save £1000 per month over an item that will make £200 a month is a simple decision and makes prioritising fast. There will be times when a stakeholder will throw their weight into the mix and make the decision for you but by educating all involved that value is the number 1 priority of the delivery team to best serve the organisation you can ensure a teams efforts are being put to work on the right things at the right times.
Item A is estimated to take 2 developer days to deliver and will yield a benefit earning of £300 per week.
Item B is estimated to take 4 developer days to deliver and will yield a benefit saving of £800 per week.
By prioritising based on value delivered to the organisation I would focus on item B because although the work will take more effort and possibly more time, it will be of greater benefit to the organisation. This is the 80/20 or Pareto principle at work, whereby 20% of your effort will deliver 80% of your gains. Over time you are aiming to be delivering smaller and smaller value items knowing the big ticket items have been completed and you are now squeezing out the smaller, but also beneficial, value tasks.
This task also helps to flush out valueless tasks. On multiple occasions I have observed tasks created and constantly pushed down the priority list to be addressed later, only to see that item hang around for up to 2 years. I say up to 2 years because that is my cut off point from a task being declared to me actively deleting the item completely.
If nobody has acted on something in 2 years the task is definitely not priority. I’d even say a task that does not move from Icebox to Product Backlog in 6 months is just an idea someone had at some point but were not willing to put in the time and effort to define the specification.
If you do not put in the effort to communicate a desired outcome effectively, you cannot expect a development team to put in the time and effort to guess, based on substandard information, what you expect to be presented on demo day. Declare the value proposition, define the outcomes, and empower the team to deliver the best solution to achieve those outcomes.