There’s a new feature that can bring in a valuable customer. The appetite is 6 weeks, but through shaping the team believes they can do it in 3.
Does the engineering team get those additional three weeks to take on some tech debt with that project? Or would the time allotment be cut to 3 weeks and sent in with another 3 week project for a small batch team?
You end the cycle early and start the cooldown for this team earlier. During cooldown, they then can take care.
Hey, good question!
First of all, the idea that “we just need this one feature to win the customer” generally leads to a bad place. Far too often those sorts of features are built and don’t materialise in actual valuable customers, so I’m always a bit cautious with that. Let’s put that aside though.
When I shape work what I’m really doing is defining the boundary of within which there are several dozen possible versions of “it” that could be delivered. It’s generally impossible to define every single detail of the project up front as we’re often dealing with lots of unknowns, but through shaping I can define constraints and boundaries to give shape to the project.
The appetite is one of our main inputs to control that boundary. With a longer appetite we increase the number of possible versions, and we might need to define more constraints elsewhere.
The question really is whether you believe the range of versions you get with a three week appetite would satisfy and fulfil the needs of the project with an acceptable cost. If yes, then make it a three week small-batch project. If no, then make it longer.
I’d be wary about tech debt. It depends on a lot of context but you generally want to factor it into your shaping. If you’re continuously smashing out feature after feature without care the team will soon find themselves stuck. There may well be a two week version of the project that creates many many headaches in the future – you likely don’t want that version of the project.
Finally, what you do after the project can vary a lot depending on your general setup. If your cycles aren’t aligned with other team cadences then you might choose to take an early cool-down and fix some bugs. Alternatively, you might find some other small batch project to follow up with.
My personal vote would be to keep your cycle time consistent and add another 3-week-appetite project IF your engineering team has been accurate in the past with their “estimates” for completion.
But if the team has a history of underestimating difficulty, or running late, keep it 6, e.g. 6 but maybe with fewer people needed (if possible).