The Story Point Conundrum

Did you know, that story point only meant the complexity of the work and had nothing to do with actual estimation of work? But unfortunately, in real world, we always need a plan and that is what I wanted to share with you all today, how does a PO get to a road-map, that is not only correct from a functional cross-dependency stand-point, but also from an estimate perspective.

The moment I say estimates, pure agilists are going to lose their cool, but I do not blame them. The whole concept of Agile was pure and unadulterated value delivery with everything else taking a backseat.

Unfortunately in real life, money is limited, so is time (and patience of sponsors).

So there always has to be a plan that can be tweaked and re-prioritized as our understanding of the product deepens. To get to a plan, one always has to have some levels of estimates as that is the closest it gets to money and money speaks volumes.

Let me try and explain this with an example. Say, you have to build a user registration system. For simplicity sakes, let us say as a user, I wish to enter my details to register myself in the system. We will keep user-pass and other support features away for this case.

As a PO, you could stop at this level, add a few more acceptance and validation criteria, some error scenarios and be done with the story. As you get to grooming with your Pod, they start breaking story down and you get to estimates.

User Registration System: This is what it would typically look like in a legacy waterfall model (over-simplified for representative purposes) which is usually competency-led team divisions (the case with most service providers).

In a Pod Model with actual full stack developers, you usually would have it broken down to just these three at most.

In a highly mature and agile Pod, you get exactly what you need, a sure shot estimate for the module

All of these are fine, and helps you get to the goal of estimating a piece of work. But this might not the best way to represent roadmaps to a sponsor of the project, as he/she would only be looking to see when value gets delivered.

That is where you bring in your product owner thought process. User Registration System is a module, which must work with other systems in tandem, including user login system, user personalization, password reset, etc. Your sponsor may only need to be appraised of the estimates and roadmap at these module level. The idea is to abstract information that is necessary for each audience that you address. A technical team might be interested in how you achieve this estimated break-down, but not so for a business group of sponsors.

Now coming to the point, which of these should you use and be accustomed to. Well, the answer is, it depends. It depends on your team, how they are divided, how are they arranged. An agile Pod often consists of a complete team, from designers to developers to data analysts and so on. But rarely do they come from a single team in most of the tech organizations. Pure tech companies have all the tech members in one engineering team, but there are far fewer Uber-like companies and far more competency driven organizations moving to agile. So under such circumstances, you choose what makes sense to the team and to the management. The difficult part is to sync the management abstraction with the engineering estimates and that is why you get paid. You may not agree with me, but the ugly truth is, most organizations are not agile (not yet) and they are in the process of discovering this gap and will slowly change organizationally to compete with other tech giants. This painful process often takes from a few months to over half a decade and that is why, the roadmap and milestone plan is often one of the most difficult tasks of a product owner, a serious conundrum if you ask me.