At my current place of work, we‘ve been experimenting with two-week “sprints” (hate the term but it’s standard, so bear with me!). We spend half of the off-wee

At my current place of work, we‘ve been experimenting with two-week “sprints” (hate the term but it’s standard, so bear with me!). We spend half of the off-week sprint planning session “pruning” the backlog: pointing and discussing new tickets, and refactoring or deleting the oldest tickets. If the second half of anyone’s sprint fees thin, we add a ticket (more or less of their choice) from the backlog to their sprint. I kind of like this system, because it allows you to think in cycles both longer and shorter than the sprint. If I see some fun optimization, but know I won’t be able to fit it into my sprint, I can craft a well-documented ticket in confidence that someone will have fun getting to take care of it in the future. Backlog tickets are also a fantastic way to onboard new engineers, because the tickets come from all corners of our system: from infrastructure upgrades to copy changes. Of course this system only works as long as you have disciplined engineers. Bad tickets will drown this system. But the “checkpoint” every other week has really been all we’ve needed to keep quality consistently high.