4 ms·
Two week sprints, while not mandatory, became sort of unwritten rule and for me is one of the worst aspects because the amount of overhead and interruption vers
by elzbardico 2y ago
Two week sprints, while not mandatory, became sort of unwritten rule and for me is one of the worst aspects because the amount of overhead and interruption versus uninterrupted work routine is a really bad ratio. Out of 10 days of work, two of them are kind of bizarre special days. Even if the reviews and planning cerimonies take only one hour each, those two days have a different vibe.
Other problem is that doing any kind of deep work in a two week sprints is highly risky. You don't want to get to the end of the sprint with anything 90% done, because it doesn't matter, you're a failure. And when you have other things to do beyond crunching tickets, anything that would take more than a couple of uninterrupted days to be done become highly risky, because the deadline is there next week looking at you.
- Smeevy 2y agoI think there's a deeper issue to identify here: this model means that you and your team are 2 or less weeks from "failure" AT ALL TIMES. There's a psychic cost associated with that that doesn't really facilitate creative work. It's crazy that the term "sprint" stuck as a way to describe a development cycle. The last thing I want to do after a sprint is another sprint.
- elzbardico 2y agoVery well said, you capture what I feel but couldn't articulate.
- fragmede 2y agoin running, what do you do after you sprint? you rest, not sprint again. yet in this tortured metaphor we keep sprinting and then sprinting again and again. where's the cool down walk, where's the stretch and refuel, where's the hydration?
- codingdave 2y agoAgreed. I dislike working on Scrum teams, but I will if they are at least trying to do it well. Even so, at this point I refuse to work on a team that does 2 week sprints. It just doesn't work as well as 3 week sprints, for the reasons you outlined. So if a team has chosen that timeline, then they are going through the motions of Scrum because of "how it should be done", not because they have been reacting to their own results and retros.
- ericb 2y agoYou have 10 days of work, two of which go to planning and retro. Now you have 8. But, is there any kind of testing process before the release? Almost no one has CD. CI, sure, but CD? Almost never. So if you assume a few days for QA if you have it, now you have 5 days to work. Only, the pointing was done with "T-shirt sizes" without really knowing how to do the work, and you're dealing with code created by this very process, so it is sloppy code, built in a pressure cooker, and you have to understand what the last person did before you can extend it. You'd like to make it better, but then you'll look bad compared to anyone who doesn't roll something over to the next sprint and ships whatever hacks work, however vile. Good luck! My solution is to ignore the deadline and do what's right and explain why, as I go. This will only work with great product folks, not mediocre ones.