As our product has grown, we are considering doing mini-sprints from time to time (after every 3-4 sprints) to handle cleaning up any tech-debt, upgrading libraries and security patches, refactoring code, and increasing our test coverage. These mini-sprints would just be a one week sprint, and then we would jump back into our normal sprint schedule.
I wanted to see if others have done something similar to this, and how they have handled it within ZenHub? The sprint editor was super helpful creating our initial schedule, but I’m not sure how we would implement this new mini-sprint. Thoughts?
Richenda’s reply is full of amazing suggestions. The only additional suggestion I’ll make is that you can go back to the Sprint setup and temporarily change the schedule to one week Sprints for the mini-Sprint then set it back to two weeks after.
Thank you @Richenda.from.ZenHub and @George.from.Zenhub! These are excellent suggestions. I like the idea of just naming the sprint for maintenance and then pulling in more work of everything is completed. I’ll discuss this with the team at our next backlog goormimg session!
When I was at Canonical, we did these all the time in person. It was exactly as you mentioned: we usually brought people together to focus on technical debt, and also broader architectural and refactoring discussions.
Some recommendations
Some things I learned from this process:
We would run this over one week, in-person, generally every 3 months. The attendance was small, usually 5 to 10 people.
Always have a clear set of overall goals for the week, but don’t cram the week so full that people feel they are not accomplishing their goals.
Keep the architectural discussions for the morning sessions and keep the afternoons for work time.
Track the sprint in ZenHub, and have a stand-up every morning (first 30mins) to ensure everything is tracked and assigned correctly.
Schedule in plenty of social time and events to build connections within the team.
By the way, I also like this break down of different types of technical debt:
We have a rule of thumb of using 25% of our time for taking care of tech debt. This is continuous, which means we add tech debt tasks in our normal backlog (our dev process is a mix between Scrum and Kanban, and we don’t have sprints - just a prioritised backlog).
Taking care of tech debt is extremely important in my opinion, so if you do not normally put those items in your sprints, then I think it is a good idea to have such tech debt focused sprints with a set frequency
