We are not using ShapeUp yet, going to give it a try soon, so trying to clarify some things about the process.
What happens if you’ve allocated whole cycle to some good project and developers managed to finish it in a couple of weeks (possibly sure to not good enough shaping)?
If that happens on the week five, there is always something to improve and add tests, etc, but what if the shapers grossly overestimated complexity?
Do you usually just pull some next small beach project that you keep in some buffer (e.g. rejected on the last betting table)?
Or do you start super-long cooldown period?
Or do you end the cycle early just for the developers who are out of things to do and have a mini betting table just for them soon?
Or is it an imaginary problem that happens so rarely that nobody cares to find a good solution for it?
Not an imaginary problem. It’ll likely happen at least a few times as your whole team is getting used to the new way of working and your shapers are still calibrating their understanding of project sizes.
First, we try to make sure we don’t ignore the learning opportunity, which is that we almost certainly need to fine tune our bets. Beyond that, we take it on a case by case basis. Encourage your devs to see it as an opportunity to tend the garden and make the software better for the long haul. Sometimes there’s a big wish list item (a big refactor or something) that one of the devs wants to do, so they’ll take a few weeks to slowly step through that, using it as an opportunity to put into practice some things they’ve learned recently.
I would encourage you to avoid offering it up as spare capacity for interested parties to fill with another project. That creates incentives that’ll ultimately put maximum pressure on your team at all times. One of the joys of Shape Up is that teams have an opportunity to breathe and do their best work, which results in better systems and keeps good devs around for the long term. It’s a virtuous cycle.
Simple answer: that’s a great problem to have (or progressively more common as shaping vs teams evolve into optimal sync).
I usually recommend that time to be used as a design challenge for the team to suggest small to mid-size incremental improvements. Depending on how much time is left, they can engage ideation and prototyping in time for testing (or even release, if minor) during cooldown.
If the team is keen, it’s a great opportunity to enable them to create something new that they are proud to have created themselves.
Other than the above, pick-up the cooldown focus early, reversing the above.
Idleness isn’t something anybody (including the team) would appreciate anyway.
PS: if the gap is too stark, that indicates that the pitching is too conservative and work has been overall under-bet upon.