5 ms·
I’d argue the predictive power of story point methodology has not been established. There are simply too many variables to make estimates more accurate than “be
by sidlls 6y ago
I’d argue the predictive power of story point methodology has not been established. There are simply too many variables to make estimates more accurate than “best guess”:
1/ the team’s composition at a point in time (and all the variability that comes with this)
2/ the team’s dependencies (a kind of exponential effect is at work here: the team’s dependencies also have all these issues in variability and so do their dependencies)
3/ the type of work being estimated in the context of the product (even “basic” things like “CRUD” can be quite intricate in some cases)
Basically unless the estimation is literally for a known change (e.g. modify source code files X, Y and Z with code changes A, B, and C) its predictive power diminishes substantially.
It’s not a powerful tool, it’s a micromanagement technique disguised as a tool to empower ICs.
- steelframe 6y agoI completely agree with the impact of the variables you listed. However it's often the case that you need a starting point to estimate timelines. It's never acceptable to tell the decision makers, "We really have no idea how long this will take." Nor is it acceptable to say, "Sure, we'll have it ready in <licked finger in the wind> 8 weeks! Everyone get to work and make that happen (or else)!" Having a concrete plan ("micromanagement?") for getting to the finish line is important, and the story point methodology is an intuitive tool for figuring out what lengths the tasks need to start out with on the timeline.
- sidlls 6y agoHaving a concrete plan with estimates is important. Assigning some "point value" to them, which variously means "complexity", "man-day-equivalent", "man-sprint-equivalent", and possibly others depending on (arbitrarily applied) context and individuals involved, is the gateway to micromanagement. It's entirely possible to provide meaningful estimates of both complexity and time-to-implement without resorting to story point formulations or any particular PM framework. "This will take about 6 weeks and has a few dependencies and unknowns that make it moderately risky to take longer." Rephrasing that as "This will take 3 sprints and has a story point value of 8 points per print" doesn't add any value, except from management's perspective as a way to put some "objective" quantification to the problem of estimates and deliverables.