[pointyfence]

We had a much more primitive version of this for our product roadmap. After working with mostly the same dev team for a few years, we felt that in a given year we seem to consistently be able to complete X “big” projects, Y “mediums” and Z “smalls” despite all the random stuff that invariably pops up.

So that list was the spine of our annual planning, the stuff that we really prioritized. The rest of the stuff that people wanted to do would have to fall in between the gaps of that master set.

It worked surprisingly well for us, but we had to build this group experience first. After a few years with another dev team at another company, I brought it up as an alternative to over ambitious roadmaps and it worked well there too.

How much of this was just due to more team familiarity and experience or this oversimplified process? Don’t know. But it felt like the roadmap trade offs were more thoughtful, devs felt more relaxed and had reserves if we had to red line a bit, and fewer missed commitments.

[ohthehugemanate]

this is the recommended way to plan time in scrum and many other agile implementations. You're just using "T shirt sizes" rather than "story points". It's recommended because it's quite accurate, as you've found!