Some organizations suspicious of relative estimation “enhance” their estimations with other methods offering a veneer of sciency-sounding objectivity; “Function points” or “Complexity Points” are some you may’ve heard of. These methods often feature schemes that calculate predicted operations, algorithmic complexity, or even simply lines of code. Without going into the weeds, the failure these schemes have in common is in trying to objectify the inherently subjective.
Remember that story points for user stories should take many aspects of a story’s size into account, including complexity. I like to consider three rough concepts for synthesis into a user story’s estimate (in story points): Risk (the known unknowns and the likelihood of unknown unknowns); Complexity (versus simplicity); and Effort (how much ‘work’ or how difficult that work might be).
Note that none of these are mutually exclusive. There’s considerable overlap, because these after all are only loose, gut-feel concepts; We shouldn’t forget that when estimating any backlog item, we can’t know everything. What’s most important is team collective gut feel of how big the item is relative to others they’ve done or are in the backlog.
For this reason, I’m suspicious of estimation formulae, schemes, and methods that have the appearance and appeal of science and precision where in reality there is none. Objective units don’t work for software development because nearly all solutions are custom-made every time and are judged by nearly purely subjective criteria.
So save the effort of laborious estimation schemes, and don’t bother fooling yourselves: there’s only gut feel and low-precision, relative sizing. If you apply yourselves well to those two things and your team is stable and truly cross-functional, with experience, the consistency and forecasting value of your velocity history will give your business partners what they need to look forward and plan – without the pretense of control & precision promised by vaporous notions of objectivity.