3 ms·

I think this is a result of a lack of granularity in the styles of stories. I worked in a heavy XP shop and we were consistent in ensuring stories were units of

I think this is a result of a lack of granularity in the styles of stories. I worked in a heavy XP shop and we were consistent in ensuring stories were units of value, chores were things that needed to be done to enable the delivery of value, and bugs were just that. Additionally, we didn’t point bugs and chores because points are supposed to be a measure of delivering value. If you have stories as units of work, your points just became yet another measure of a unit of work. Also, having worked in the XP shop and a “traditional Agile” shop, we never preplanned sprint work. We worked in one-week iterations as a means of bookkeeping, but we never committed to work ahead of time. We just pulled off the backlog and kept going. Some weeks we’d get more done, some we’d get less, but we had a trend line of velocity that gave us a projection of how much work we’d get done. I don’t actually care much for committed-work sprints as a means of getting work done. It just doesn’t feel useful.

simonbarker87 5y ago
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.
marcosdumay 5y ago
> We just pulled off the backlog and kept going. This is called "kanban" in agile-speak, despite it being basically the inverse of that term's original meaning from production engineering. And yes, I completely agree that timeboxes are counterproductive. It just takes the least reliable part of software engineering (task size estimation) uses it as the fundamental tool for organization or all activities.

simonbarker87 5y ago

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.

marcosdumay 5y ago

> We just pulled off the backlog and kept going. This is called "kanban" in agile-speak, despite it being basically the inverse of that term's original meaning from production engineering. And yes, I completely agree that timeboxes are counterproductive. It just takes the least reliable part of software engineering (task size estimation) uses it as the fundamental tool for organization or all activities.