4 ms·

I've seen "story points" be totally useless over time on teams where "number of tickets delivered per week" was remarkably stable. But people don't like using

I've seen "story points" be totally useless over time on teams where "number of tickets delivered per week" was remarkably stable. But people don't like using that for some reason.

tharkun__ 5y ago
If you do that you can actually very easily switch to Kanban methinks. In Kanban you sort of have to size all work to be about (!) the same size so that you can make accurate enough predictions for your lead time and cycle time. That only really works if all work items are about the same size though, otherwise you get too many outliers from your statistics. I've found that most Product Owners really care about predictability and less about actual estimates. They care that if you say you're gonna finish something by the end of the sprint, much more often than not, you will. Estimates and velocity and such things are just means to the end of trying to figure out which items are reasonable to take into a sprint together. If your Product person knows that they can throw 10 "random" (but currently most wanted by stakeholders) work items into a "sprint" and 9 times out of 10 you will actually finish all of those, they're probably gonna be very very happy as they won't have to explain delays over and over again on their end.
robertlagrant 5y ago
> I've seen "story points" be totally useless over time on teams where "number of tickets delivered per week" was remarkably stable. But people don't like using that for some reason. I don't see how this can be the case. If each ticket is estimated to be about the same size, and it sounds as though they should be, then if you're doing say 5 tickets a week, 10 a sprint, and they're all about the same size then each ticket you could say is 5 points, and you're doing 50 points a sprint. That's probably pointless (hah) if they are all the same size; ticket sizing is more for if you have tasks of different sizes and you're trying to roughly combine them into something you can predictably deliver. But if you're at a stage when your delivery is already this predictable, you may not need to use story points particularly. If it's mandated for some silly reason then you could use the above method to bat it away quickly!

I've seen "story points" be totally useless over time on teams where "number of tickets delivered per week" was remarkably stable. But people don't like using that for some reason.

tharkun__ 5y ago

If you do that you can actually very easily switch to Kanban methinks. In Kanban you sort of have to size all work to be about (!) the same size so that you can make accurate enough predictions for your lead time and cycle time. That only really works if all work items are about the same size though, otherwise you get too many outliers from your statistics. I've found that most Product Owners really care about predictability and less about actual estimates. They care that if you say you're gonna finish something by the end of the sprint, much more often than not, you will. Estimates and velocity and such things are just means to the end of trying to figure out which items are reasonable to take into a sprint together. If your Product person knows that they can throw 10 "random" (but currently most wanted by stakeholders) work items into a "sprint" and 9 times out of 10 you will actually finish all of those, they're probably gonna be very very happy as they won't have to explain delays over and over again on their end.

robertlagrant 5y ago

> I've seen "story points" be totally useless over time on teams where "number of tickets delivered per week" was remarkably stable. But people don't like using that for some reason. I don't see how this can be the case. If each ticket is estimated to be about the same size, and it sounds as though they should be, then if you're doing say 5 tickets a week, 10 a sprint, and they're all about the same size then each ticket you could say is 5 points, and you're doing 50 points a sprint. That's probably pointless (hah) if they are all the same size; ticket sizing is more for if you have tasks of different sizes and you're trying to roughly combine them into something you can predictably deliver. But if you're at a stage when your delivery is already this predictable, you may not need to use story points particularly. If it's mandated for some silly reason then you could use the above method to bat it away quickly!