4 ms·

I like some aspects of it, mostly the ability to say, when someone asks for something to be done Right Now, "here are the things I'm committed to for the next t

I like some aspects of it, mostly the ability to say, when someone asks for something to be done Right Now, "here are the things I'm committed to for the next two weeks. Which of them should I not do to make room for this new priority?" I do NOT like the idea of a hard beginning/end of sprint, it's a pipeline stall. I generally like to have something I'm planning, something I'm working on, and something I'm working through review on. If I have to be 100% delivered at the end of the sprint that means I have to budget to be finished with all work and just be sitting around herding PRs the last 2-3 working days. We don't do sprint planning until the first day of the new sprint so I can't really start speculatively executing on next sprint. So I usually overcommit a bit just so I will have stuff in progress at the end of the sprint, and then just eat the PM stinkeye when we don't burn it all down.

JohnBooty 3y ago
"here are the things I'm committed to for the next two weeks. Which of them should I not do to make room for this new priority?" Yeah. People will scoff at this and say that you don't need agile or sprints for this. And they're correct, but naive. Certainly I have successfully done this in the past without fancy agile religion or ceremony. In fact it's a valuable skill for any job in any industry. But it has always been hard to do and I'm sorry, but most people (both engineers and managers) are bad at it most of the time. The industry clearly needs help with this concept.