3 ms·

> Every third sprint is a tech sprint. Can you elaborate on this? I love the sound. I get pushback even suggesting a tech sprint once every 6 weeks. What kinds

> Every third sprint is a tech sprint. Can you elaborate on this? I love the sound. I get pushback even suggesting a tech sprint once every 6 weeks. What kinds of projects fall under here, and do you still work on product? What's the product team work during this sprint? Thanks!

zerof1l 6y ago
It is very similar to a normal sprint, but instead of adding new features, our goal is to improve existing features, the system, or the process. It can be technical things like upgrading to a new version of PHP, of a framework, or a library. It can be anything related to technical debt. It can be some proof-of-concept. In one of such sprints, I've introduced cypress and made a couple of tests to demo it. The tickets for this sprint come from anyone. Usually, when working on a ticket you sometimes get a brilliant idea. Write a new ticket with that idea and add it to the tech sprint proposal. Before the tech sprint, the whole team participates in sprint planning. We go over tickets, review them, and decide whether they should be done. Usually, we assign tickets to ourselves. We also estimate how many story points they will be. Ideally, it should take less than 1 week to finish. A maximum of the whole sprint of 2 weeks is allowed. Otherwise, it is divided or multiple people work on it.
908B64B197 6y ago
> I get pushback even suggesting a tech sprint once every 6 weeks. Either get a dedicated team for this or a better manager.
herval 6y ago
IMO the problem with this approach is it draws a line between “tech debt” and “progress”. So in the end, the team will overcompensate to do less and less “tech debt sprints” or start expanding it into an occasional “tech debt half”, and so on. What I think works better is having a tech debt related goal _as part of product work_: instead of estimating you’ll work on feature X, also add time and be explicit about tackling issues around X. This also prevents wasting time on debt that’s not really relevant (is a piece of code that never fails and never change really worth rewriting?). This makes it easier to tackle it over time, easier to sell to product & management. “Tech debt” itself is a bad term IMO - it isn’t an aspect of software that’s easily identified (unlike, say, compilation warnings), and you can’t count it as money-debt, so I always found the concept of “paying it down” sorta counterproductive. But that’s a different topic altogether.

zerof1l 6y ago

It is very similar to a normal sprint, but instead of adding new features, our goal is to improve existing features, the system, or the process. It can be technical things like upgrading to a new version of PHP, of a framework, or a library. It can be anything related to technical debt. It can be some proof-of-concept. In one of such sprints, I've introduced cypress and made a couple of tests to demo it. The tickets for this sprint come from anyone. Usually, when working on a ticket you sometimes get a brilliant idea. Write a new ticket with that idea and add it to the tech sprint proposal. Before the tech sprint, the whole team participates in sprint planning. We go over tickets, review them, and decide whether they should be done. Usually, we assign tickets to ourselves. We also estimate how many story points they will be. Ideally, it should take less than 1 week to finish. A maximum of the whole sprint of 2 weeks is allowed. Otherwise, it is divided or multiple people work on it.

908B64B197 6y ago

> I get pushback even suggesting a tech sprint once every 6 weeks. Either get a dedicated team for this or a better manager.

herval 6y ago

IMO the problem with this approach is it draws a line between “tech debt” and “progress”. So in the end, the team will overcompensate to do less and less “tech debt sprints” or start expanding it into an occasional “tech debt half”, and so on. What I think works better is having a tech debt related goal _as part of product work_: instead of estimating you’ll work on feature X, also add time and be explicit about tackling issues around X. This also prevents wasting time on debt that’s not really relevant (is a piece of code that never fails and never change really worth rewriting?). This makes it easier to tackle it over time, easier to sell to product & management. “Tech debt” itself is a bad term IMO - it isn’t an aspect of software that’s easily identified (unlike, say, compilation warnings), and you can’t count it as money-debt, so I always found the concept of “paying it down” sorta counterproductive. But that’s a different topic altogether.