[tiagogm]

Kanban lends itself well to this.

Breaking down work into similarly sized tickets/units can, over time, be used to predict delivery/capacity (which one can use Cycle time to calibrate)

Even neater with enough data it becomes possible to use Monte Carlo simulations to give you confidence intervals on how much can you do or how long you will take to do X amount of work.

https://kanbanize.com/kanban-resources/kanban-analytics/mont...

I find this approach a lot less time consuming, more predicable and reliable.

[al2o3cr]

    Breaking down work into similarly sized tickets/units can,
    over time, be used to predict delivery/capacity

IMO "can break up work into similarly-sized units" is equivalent to "can estimate accurately".

Re: that article - I can't imagine many things LESS accurate than "we have 104 tasks on the board and each team member's cycle time is 2 days so we can finish all the tasks with 10 people working for 20.8 days". Yeah, it makes for a nice graph - but it omits important details like dependencies...

[regularfry]

That's not how it works, though - you never deal in terms of individual team members. The team is the unit of delivery. Otherwise you end up with people who should know better putting more people onto teams to "help".

Teams above a certain maturity level do often settle on a certain number of delivered tickets per month, and when you're looking at that sort of resolution, dependency problems and other factors like those you mention are represented in the data. It's not so much a measure of how productive the team is, it's a measure of how much work the team can get done embedded in the organisation they're in, which covers off their ability to resolve blockers and communicate with other teams.

There's a very different cognitive framing if you count tickets, too: you're not saying to the team "come up with a number, you're going to get shouted at if it's wrong, and you've only got 10% of the relevant information to hand", you're saying "do your usual design process, and we'll use the output to make a projection based on the history." Functionally it might be equivalent to "can estimate accurately" but it doesn't work like that when you're the one in the hot-seat.

[tiagogm]

True, I do find it easier and a less time consuming to break a large piece of work in around 2day chunks (for example) than using different sizes or trying to decide if something is 3 or 5.

In the end, regardless of whatever scoring strategy you use it should always be team centric, rather than individual.

It is possible to say, over the past 6 months, and X tickets, our team has had a Median/Avg cycle of around 2days. If team breaks future work in similar sized chunks, it can very fairly confidently predict how long they will take to do X more tickets, assuming similar conditions.

The added benefit of using small chunks of time, is that one does not need to be super accurate (in most scenarios), it can be 1 or 4 days, all it matters is it's possible to give window of estimation (based on actual data, not guesses) with a certain degree of confidence. (which will naturally become even more consistent over time)

[vosper]

> IMO "can break up work into similarly-sized units" is equivalent to "can estimate accurately".

Yeah, agreed. What I've always seen is "break up work into logical units, ideally as small as possible" which always ends up with a mixture of tickets of different sizes.