2 ms·
> To the contrary -- in between each sprint, there's a review, a retrospective "in between" is overstating things a bit. The current norm seems to be two week
by stormbrew 4y ago
> To the contrary -- in between each sprint, there's a review, a retrospective
"in between" is overstating things a bit. The current norm seems to be two week sprints and all these things are done at the beginning and end of them. To be honest, I personally do feel like this gives the feeling of 'sprinting' because it usually means at least 2-3 days of the sprint are 'wasted' on meetings and that counts for a lot when it's 2/10 or 3/10.
And a lot of the terminology around this kind of process are geared to give you a sense of urgency. Right back to "Extreme Programming".
- vosper 4y ago> The current norm seems to be two week sprints and all these things are done at the beginning and end of them. Everywhere I've worked that did "agile" did it this way. The ending of a sprint is always the start of the next one; teams are always in a sprint. If that part of the process can't be changed or removed then one of the best things to do is decouple the sprint cadence from other events. Eg don't put demo, pointing, planning, and retro on the same day. Try to do pointing mid-sprint, if you know what's coming up, so that you're not cramming it in at the end. Don't release to staging/prod at sprint boundaries, do that mid-sprint. The worst is to clump all the meetings, distractions, and stresses together.
- stormbrew 4y agoI mean whether you clump them or not they're still time taken out of a very short period. I wouldn't (and haven't) minded so much with longer sprints, but 2 weeks minus planning/retro minus "one person takes a Friday off and another person is out one of the weeks" always leaves me feeling cramped. I think the best structure I ever had was 3wk "actual work" sprints and 1wk to address tech-debt and do planning.