The place I work says they do this and will chain with a straight face that our sprints are budgeted to allow approximately 20% slack time.
This is of course not even remotely true in any practical sense. I have not received an explanation for how it’s even possible when sprint targets are intentionally set at slightly more than was done in the previous sprint, every sprint.
Hazzard@lemmy.zip 4 weeks ago
Haha, you’re not wrong. Ours tend to ebb and flow with whatever urgent priority upper management has set as well, and it tends to take slack alongside our tech debts. Our management is listening and getting better though, I’m hopeful that in a few years we truly will catch up on our tech debts and have all our managed products in good shape at once.
That said, even in that environment, we’ve had some pretty incredible 20% success stories. Some of my own experiments from when I’ve had the time have become proper released features, although I mostly use it to skip the bureaucracy and address my pet peeve tech debts, which isn’t the point but is nice to be able to do. And one of our major internal products, with a large dedicated team and roadmap, began as one developer’s 20% project a few years back.