2 ms·

In time boxed sprints it annoys me no end that ONLY stories get pointed and then a “percentage of the sprint” is reserved for unpointed work. Given that points

In time boxed sprints it annoys me no end that ONLY stories get pointed and then a “percentage of the sprint” is reserved for unpointed work. Given that points aren’t allowed to equal time and bugs and chores are allowed to be pointed the question becomes “a percentage of what exactly?” Removing the time bounding makes much more sense as you’ve said above. I have this argument with my PO and SM - if points don’t equal time then why do we plot points vs time on a burn down? Not pointing work in this scenario is just a way for management to squeeze extra work in that looks free.

Spartan-S63 5y ago
Yep, the conflation of points into time-spent is a perversion of Agile and creates an incorrect metric for value delivered to the user. If you look at points as a lagging indicator of time estimation, it’s much more valuable as you can establish trends and look at those trends versus team strength, etc. Additionally, if you use the ratio of stories, bugs, and chores as a leading indicator of product/team/codebase health, you can make intelligent decisions about when larger refactors are necessary. If you find yourself spending more and more time on bugs, you might want to take a step back, assess the cause and invest in fixing it. Basically, getting rid of timeboxing, establishing team SLOs on portion of work (such that breaching your error budget requires refactoring/paying down tech debt/halting delivery of new value), and ensuring points are only assigned to value-producing work, would result in a better process and clearer outcomes and impact.
crucialfelix 5y ago
To me, points should be an estimate of complexity. Higher complexity means more unknowns, more traps, larger possible range of time to complete. If the current codebase is murky, then I add points. I promise that if we fix the murky areas in the code then we can build faster and more predictably. A 1 pointer means nothing can really go wrong. It's a linear time task. I don't think the Product Manager digs my philosophical approach.

Spartan-S63 5y ago

Yep, the conflation of points into time-spent is a perversion of Agile and creates an incorrect metric for value delivered to the user. If you look at points as a lagging indicator of time estimation, it’s much more valuable as you can establish trends and look at those trends versus team strength, etc. Additionally, if you use the ratio of stories, bugs, and chores as a leading indicator of product/team/codebase health, you can make intelligent decisions about when larger refactors are necessary. If you find yourself spending more and more time on bugs, you might want to take a step back, assess the cause and invest in fixing it. Basically, getting rid of timeboxing, establishing team SLOs on portion of work (such that breaching your error budget requires refactoring/paying down tech debt/halting delivery of new value), and ensuring points are only assigned to value-producing work, would result in a better process and clearer outcomes and impact.

crucialfelix 5y ago

To me, points should be an estimate of complexity. Higher complexity means more unknowns, more traps, larger possible range of time to complete. If the current codebase is murky, then I add points. I promise that if we fix the murky areas in the code then we can build faster and more predictably. A 1 pointer means nothing can really go wrong. It's a linear time task. I don't think the Product Manager digs my philosophical approach.