Post by @polotek@social.polotek.net

@polotek@social.polotek.net

2024-05-01 23:19 UTC

Here are some the heuristics I tend to use. * If you're giving hard estimates further than 3 months out, you're probably making it up. * We can and should break large efforts down into phases or milestones. Those should target 3 months or less so the estimates can be meaningful. * Getting good at swaging these 3 months milestones means you *can* give fuzzy estimates about large efforts. 4-5 milestones means "this could easily take 18 months".

Replies (2)

@polotek@social.polotek.net 2024-05-01 23:21

* Estimates will vary greatly based on the size and experience of the team. * Part of the job of a project lead is to break down the work into manageable chunks. This is largely where we *design* the system to be built. Hint: this part is missing in a lot of dev processes. * Below two weeks or so of work, the ownership should be given directly to the engineer who will do the work. If they say yes, then we're good. As I told someone earlier, I hate "story points" with a fiery passion.

Open ##2300374
@brunogirin@mastodon.me.uk 2024-05-02 13:55

@polotek@social.polotek.net as a product manager, that's more or less what I do with my team: * plan a piece of work that looks like it should fit in a quarter based on what we did the quarter before, * break the effort down into stories, in a collaborative way with the dev team so they can give an estimate for each story, * review total estimate against total of previous quarter and adjust scope if necessary, * prioritise leftover scope as stretch goals.

Open ##2300416