Don’t use Story Points, use Value Points instead

There is a large portion of those who work in Agile, who do not like nor want to use story points to measure the ‘size’ of a team’s work. Though I understand the various reasons, we need to have a way to measure the potential size of our work as this represents the investment, we’ll be making to deliver what is being requested by the business. The size of something, be it by points that can be converted to the number of sprints or just sprint estimates based on the potential number is wat we can use to establish the cost or investment needed to deliver something of value.

And though I often use story points as a primary way to establish a team’s capacity to do ‘work’, the reality is if we are going to continue to plan and fund work in traditional ways, then we need something to identify a team’s capacity as a planning input and provide guardrails to our teams. Without understanding a team’s capacity, most organizations push more work onto their teams than they can do, causing a reduction in both productivity and quality.

It now seems that everyone is jumping on the value bandwagon but for the most part in the agile delivery world, value is merely a word we use, not a disciplined approach to value identification.

My QValue Portfolio Scoring Model provides the necessary approach and framework to deliver value points that are tied to quantifiable outcomes. Instead of managing by a funded plan, what if I could provide you with a way to manage by value delivered? My model can tell you when to stop investing in work as you have a way to ‘see’ the value delivered. You can easily see the intersection of cost vs return so that you don’t over-invest in features that don’t deliver real value.

This approach does require a significant change in how we work:

1. Fund teams — Managing by value means your focus is on funding the right level of capacity in each of your Business Capabilities.

2. Intake — Work will be approved and prioritized by value, not by the loudest voice. Ditch the work ‘Demand’ as it has an assumption that the request will be completed.

3. Develop Value Realization metrics and dashboards — There will be a natural lag between something going to production and determining if we received value for it. During this lag, teams will shift to the next most valuable work until metrics determine they either need to deliver more value or stop any further development efforts.

4. Focus only on the most valuable work — This will provide the necessary guardrails to manage the flow of work to teams, keeping them from becoming over-committed.

Agile wasn’t developed to make us go faster, though that seems to be all anyone seems to care about. No Agile was about aligning business and development groups more tightly so that they could focus on delivering value more effectively. But instead of defining a value model to work from, the Agile Manifesto fostered the development of a bunch of frameworks that are almost entirely focused on how we work, not what we work on.

This must change and QValue offers a way forward in making real agility a reality for your organization.

Want to learn more or engage me to help build your Value Model?

Contact me at michael@soundagile.com or go to www.soundagile/qvalue