T-shirt sizing. Fruit Sizing. Planning pokers. You might be familiar with any or all of these estimation (relative sizing) techniques. Story points based estimations (along with velocity mapping) is touted as a predictable method to plan for software delivery. Teams are expected to get a good sense of the effort needed to deliver a piece of work by comparing estimates with references of similarly complex work they have delivered in the past.

The accuracy of point based estimates fares more or less in the same range as sheer gut feel. So, the natural inclination for software teams is to try and make it more accurate than gut feel. Thereby, we obsess with breaking functionality into smaller byte sized stories. We freak out when there is "scope creep". We debate endlessly about ideal days vs. person days. We fuss over the specific visual representation for the burn-up or burn-down.

Does it matter anymore how many days the team spent chipping hard at a feature that added no value to the business? Have we made agile teams into mini waterfall teams by focussing on the wrong metrics? Can product companies afford this?

Process heaviness in product companies can cost a lot. We need to find better ways to invest in success metrics. We need to change the conversation from productivity to value add.

My talk intends to challenge prevalent estimation practices and contest their validity in product companies. I will also introduce ideas around capturing relevant business metrics and sizing stories using business value.

Business value is a rather abused term in product teams. We continue to drive development teams to understand the business value of what they're building. Business goal posts are ever changing. But do business teams themselves understand how to differentiate between "just an idea" and "an idea worth pursuing" ? How should product teams ensure that priorities are based on measurable & actionable success metrics, not just an idea that sounds important ? 

My talk is to demystify business value by creating a framework for quantifying business value. 

Understand business value points

Measuring product progress based on business value points (rather than story points )

Sustainable product iteration based on success metrics tracking. 

My talk will be most useful for teams aiming for Lean delivery, with a greater emphasis on outcomes rather than processes.