it’s been a while! Hope you can finally start to enjoy the early summer. Judging from the traffic jams and increasingly packed parking lots here in the South, it would seem you are!
So if you’re out and about, the following will be tldr. If you’re stuck in one of the traffic jams, I guarantee this will be more edifying than your Pinterest or Twitter feeds!
There is a perennial discussion why Agile development may be faster than Waterfall. Just try a Google search on the topic.
The truth is, Agile development is not faster as such. Great developers will always code as fast as sensible under the circumstances.
The difference is, that Agile backlogs are continuously optimized to deliver maximum value to customers – and stakeholders at large. Waterfall development follows a project plan that is optimized to deliver a defined end result at a pre-defined point in time.
True digital product development is not about delivering a pre-defined end result (e.g. a feature X), an output. Most successful digital products are about solving stakeholder problems, e.g. minimizing order processing time, that is, iteratively improving towards an outcome.
Digital products are for that reason continuously optimized until an agreed or accepted state is achieved as outcome.
When developing products in an agile way, the Product Owner(s) will always try and prioritise the work that will deliver the greatest value per estimated development effort towards stakeholders‘ desired outcomes.
In scaling and complex environments, the assessment of the greatest value/effort becomes paramount. The below is an edited version of a longer piece I recently wrote for one of our clients‘ wiki on the subject.
The concept of business value is an informal term that goes back to management guru Peter Drucker. It conceptually expands value generation beyond pure economic (shareholder-) value.
Business Value describes the benefits a business generates for its stakeholders.
While not necessarily immediately translating into economic value, business value always contributes to the business’s overall health.
Stakeholders include for example:
- customers who pay for the product or a functionality
- users who apply a function; e.g. end-users using a function for their work
- the firm’s management looking for business benefits
If a product – or by extension one of its components or functions – does not contribute to measurably fulfilling a stakeholder’s need, it carries no business value, and spending time and effort on it has to be considered a wasteful activity.
Examples of Business Value
There is any number of ways Business Value can express itself.
Some factors for consideration:
- Commercial Value: the ability to bill for a product, service, component, or feature; usually measured in revenue.
- Strategic Value: something’s criticality to reaching a strategic business objective or OKR; KPIs here would depend on the respective strategic goal or Key Result.
- Market Value: the increased ability to attract new customers; a relevant KPI would e.g. be customer acquisition cost (CAC) or its reduction.
- Efficiency Value: decreasing the time to market or the cost of delivering a product or service. Measured e.g. in $$ saved.
- User Value: creating functionality that makes some job easier and is therefore requested by users. This can e.g. lead to time saved any instance some action is performed, or higher customer satisfaction; This can be measured in direct time and/or cost savings. Satisfaction also increases customer retention rate, indirectly customer acquisition cost and cost of sales generally.
- Future Value: e.g. reducing technical debt in code; This can ultimately be gauged in reduced maintenance cost or avoided cost-of-delay.
Combinations are possible.
To estimate value per implementation effort, I do consider four parameters key:
- the number of people or units impacted by the functionality (often referred to as „Reach“): stakeholders at large, customers, users, …
- the magnitude of the „Impact“ – time, $$, …, gained or saved by implementing and operating the functionality or service, often more easily assessed by etsimating the impact of not implementing it (Cost of Delay) – ultimately an attributable monetary value
- strategic value – how much the requirement is aligned with strategic objectives. Normally this value is applied comparatively by Portfolio- or Product Management, applying e.g. a Fibonacci scale.
- delivery effort – the effort required to deliver the requirement. This is again typically estimated in relative terms by the development, typically translating T-shirt sizes into a Fibonacci sequence.To be able to deliver highest value and applying the comparably lowest implementation effort first, Reach, Impact, as well as delivery Effort, need to be transparently substantiated.
Here are some views on prioritisation at scale:
Cost of Delay and CD3 Prioritisation at Scale
Blackswanfarming’s article discusses the application of CD3 – Cost of Delay Divided by Duration – at scale.
Click to view!
A hack I use to estimate Impact/Effort
(This should be applied on e.g. JIRA’s „Initiative“ or „Epic“ scale). To asses the relative value of a backlog item, I suggest assigning e.g. SAFe’s modified Fibonacci Scale from 1-20 (1,2,3,5,8,13,20) for each item in three categories:
- Impact – The impact of not delivering the item in a business relevant time frame, e.g. the next quarter (20 = catastrophic, blocks product launch or similar; 1 = minor, may cause a nuisance to someone). Impact should be provided by Product Management working with Sales, Customer Success, ….
- Strategic Value – Roadmap or other strategic priority fit (20 = undisputable strategic requirement, directly linked to a strategic initiative, OKR, or similar; 1 = Item is loosely attributable to some strategic goal). Strategic value in my view is ultimately to be decided by Product Managers.
- Estimated Effort – Relative effort on a numerical Scale – translating the customary T-Shirt size estimates (e.g. XS=1, S=2, M=5, L=13, XL=20).Multiplying Impact estimates with Strategic Value provides a good proxy for relative business value. Dividing it by the – again relative – estimated effort translated from XS, S, M,…, per the above, into the modified Fibonacci scale, provides a relative value/per effort. The larger this number, the higher an item should rank in priority.
Pls. note that calculated figures are only directly comparable (much like Story Points) if estimated by the same team!
Have a great rest of the weekend – I will now be heading north towards the traffic jams across the Brenner summit…!