ZenHub Community

Connect with global technologists to get answers, support and inspiration on the best ways to build great products using ZenHub

Thoughts on a Tech-Debt Mini-Sprint?

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? :eyes:

1 Like

This is such a great question! Maintenance is a tricky thing to manage. Firstly, we always recommend an experiment so running a maintenance/tech dept focused sprint between your primary sprints is a great place to start. A couple of things to consider first before you try it out that I recommend;

  • Be honest with yourselves. Do you fully know the scope of the tech debt / maintenance that you’re tackling? Is 1 week enough time to bring these tasks start to finish?
  • Prioritize backlog refinement of the tasks related to tech debt before kicking off the experiment. This will help you understand the scope of each task going into the experiment. The goal is to be as realistic as possible with allocating resources so you can hit your goals! :slight_smile:

In my experience making time for tech debt is only half the battle. The second half is ensuring that enough time is being allotted to fully complete the tasks.

Related to how you can set this up in ZenHub; the automated sprints tool is set to fixed sprint dates with 3 sprints at time. To leverage automated sprints for this experiment I’d recommend;

  • Keeping the same 2 week sprint cadence as your regular sprints to begin the experiment. If the team finishes early they can always pull in other work.
  • If every third sprint will be dedicated to tech debt, I recommend marking these dates and customizing the name of the 3rd sprint to reflect that during your planning.
  • The other option is to leverage an epic or our release feature to capture these mini sprints if you’d like to have 1 week mini sprints :slight_smile:

Hope this helps!


Hey :wave:

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.

Hope this helps,

1 Like

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! :smiley:

1 Like

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:

Might be handy as you plan this out.


We have lots of new community members here - I’m wondering if anyone else has thoughts on running a tech debt mini sprint?

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