This document discusses unpacking and understanding business value in agile development. It notes that while agile focuses on velocity, business value is about customer success and market outcomes. True business value comes from satisfying paying customers through early delivery of valuable software. Estimating business value is difficult and projects often deliver less value than estimated. To improve, teams should negotiate real tradeoffs, prioritize like items, use reality-based budgeting, and get closer to actual users and customers.

1. UNPACKING
BUSINESS VALUE
AgileCamp Dallas
Rich Mironov
@richmironov

2. • Process improvements: throughput,
quality, building things right
• Assumes strategic prioritization and
useful market outcomes
• Does “Business Value” still taste like
customer success?
Agile’s Focus on Velocity

3. There’s nothing more
wasteful than brilliantly
engineering a product that
doesn’t sell, or a project
that doesn’t matter.

4. • “The Business” separated from “The Team”
• Assigned value, not market outcome
• Early (fixed) estimates
• Prioritizing unlike things algorithmically
• Are paying customers saying “yum?”
We’re Forgotten What Real
Business Value Tastes Like

5. Our highest priority is to satisfy
the customer through early and
continuous delivery of
valuable software.

6. • New product/service
• Promise of future revenue
• Feature/workflow improvement
• Promise of future user happiness
• Technical debt reduction
• Promise of future velocity
• Test automation, CI-CD
• Promise of faster releases
• System improvements
• Promise of future operational savings
Many Flavors of
Business Value

7. Hypothesis:
• Project business value estimates +/- 70%
• 1 in 10 will deliver zero value
Would that change portfolio planning
and stakeholder interactions?
Business Value Error Bars >>
Development Error Bars

8. 1. Negotiate real trade-offs with decision-makers
2. Relative, like-with-like comparisons
3. Reality-based budgeting (projects don’t end)
4. Get closer with actual users (paying customers)
What Can We Do?

9. Development can
never build as fast
as we can dream

10. • “CEO says it’s really important.”
• “We already promised it to a big prospect.”
• “How hard could it be? Probably only 10 lines
of code.”
• “We’ve been talking about this for months.”
• “We’ve gone agile, which gives us infinite
capacity...”
• “My neighbor’s kid could do this in an hour.”
Magical Thinking

11. • Most requests will go unfulfilled
• Roadmap: what we are building (instead of new request)?
• What commitments would we drop to add this?
• Trade-offs among like items
#1: Real Trade-Offs are
EXCLUSIVE ORs (not ANDs)

12. Features
for
current
release
50%
Quality,
test
automa6on,
tech
debt
15%
Management,
overhead,
10%
Future
R&D,
5%
One-­‐offs,
non-­‐
roadmap
20%
Typical Commercial Software
Development Budget

13. Prioritizing Within Buckets
#2. Prioritization within buckets

14. • Quick-sort top candidates
• Let us negotiate complex issues
• Live stakeholders around the table
• WSJF assumes accuracy and independence
that I rarely see
Prioritization Algorithms
Get Us 80% There

15. • Programs/products run for a very long time
• Things we dropped from V1.0
• What we learn, new needs,
platform evolution
• Yet we budget as if projects end on ship date
• Need sustaining budget until end-of-support
#3: Reality-Based Budgets

16. • External customers pay our
salaries
• Measure satisfaction,
adoption, usage, revenue
• Meet them, hear their
stories, look for joy
#4: Get Closer to
(Paying) Customers

17. • Talk in terms of paying customers
• Use your own products
• Listen in on customer calls/
interviews/UX tests*
• Ask for success metrics
• Look at revenue
• Celebrate customer improvements
Things You Can Do (This Week)

18. • Business Value is essential
• Different flavors
• Not precise enough for
auto-sort
• Sample what your real
customers taste
Take Aways

19. Rich Mironov
Mironov Consulting
San Francisco, CA
rich@mironov.com
1.650.315.7394
twitter.com/richmironov
linkedin.com/in/richmironov