Why story points make no sense for a product company

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. (that's a rather simple explanation of course. It depends on a multitude of other factors - team experience, competence, complexity, risks, uncertainty etc etc etc)

I've been part of various discussions (and fist fights) in the past about the usefulness of story point based estimations. I've never been fully convinced about it's value. 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. (wo)man days. We fuss over the specific visual representation for the burn-up or burn-down. And then project managers put in ample buffers. You know, just in case. :\

Software Service companies still stand to benefit from this process obsession. I'll give them that. After all, they need to justify their costs. Which depends on time. Which depends on estimates. Getting a predictable view on speed at which teams can deliver is important for a services company.

But story point based estimations in product companies ? Blah.

Let me try and explain why point based estimates make no sense for a Product company.

Outcomes over Effort

For product companies, only functional milestones should matter. Let us say, we need to launch a feature to beat the competition, right before the upcoming festival season. Would you deliberate over breaking down functionality to bite sized stories, and estimates ? I'd ask why the team wasted time talking and not building something ? :\

Timing is critical 

Timing is super critical for products. Market dynamics determine the best time to launch a product/ feature. When timing is critical, every activity that does not contribute to the launch is a waste. Hence products teams need to plan on "what" to deliver within the given time.

Do More with Less 

This is especially true of product startups where the "product team" is rather lean. Stories and Estimations are a luxury. Getting things out the door matters more than doing things the "right" way. After all, perfect is the enemy of good. So, the focus should be on getting something "good enough" (& measurable), rather than building perfectly upfront (which involves far too much effort on planning and estimating)

Steady team structures

We can assume a few things about a product team. At least a core product team is likely to stick around for a couple of years at a stretch. (unlike service companies, where the churn is likely to be higher. People on the team move in & out of a project more often) Context about a product resides within the team. This improves the gut feel. :)


So, does all this mean that tech teams in Product companies should just mindlessly build anything that is thrown their way ? No. Of course not.


It is important for Product companies (not just tech teams in product companies) to internalize the importance of Success metrics of a Business Goal/ Value.


Sometimes, Business Value can just be convenient concept to coerce tech teams into delivering anything that catches the fancy of the business leader (or startup founder) . This needs it's own blog. Really.

Let me explain why we need to define Success Metrics upfront.


Let's say you want to build a landing page to validate if there is a prospect of getting B2B leads for an existing product. A simple metric to measure would be - "What number of B2B sign-ups would tell us that there is enough interest for us to take concrete next steps?"


If business cannot answer that question with specific metrics , then may be the Business Value isn't as high as it is made out to be. Even if it is answered in specifics - it is possible that building even a simple landing page may be too much to invest to validate something like this. May be we leverage social media or run an email campaign instead?


I did mention "too much to invest" - which, of course, means cost. So, shouldn't we estimate? Yes. But not at the story point estimation level. Gut feel will do just fine. And you don't need your entire team's consolidated experience to arrive at "is this doable or not?" If you spend more than half an hour trying to figure out if something is "doable" within the next 2 weeks, it's not.


Let us consider the matrix below. A prioritised backlog has an active bucket that sits in Quadrant 2 (high value, must release soon) 

As timelines draw closer, backlog items will move from Quadrant 1 to Quadrant 2 (assuming business value remains the unchanged)

Product teams must figure out "what can we build to validate the success metrics within the given demands on urgency?" (MVP)

Business teams must ask "Should my team build something more valuable instead?" (BVP)





An MVP should involve thinking "if this feature has to moves to Quadrant 2, what would I not build?"

Defining a BVP (Business Value Points) is a good way for business teams to assign measurable metrics. This is something we actively track at Rang De. (More on Business Value Points and that other rant about Business Value in a different blog - coming soon :))

Process heaviness in product companies can cost a lot. Invest in defining success metrics for business goals. Create cross functional conversations that ensure business teams understand the cost vs. value.

Eliminate Waste. Stay lean.

First published here :https://www.linkedin.com/pulse/why-story-points-make-sense-product-company-mangalam-nandakumar