Should agile sprints/iterations be back-to-back?

Question

I know -- it depends, right?

What I'm asking is whether the notion that sprints/iterations in agile development should always be back-to-back, with only a review and planning meeting to separate them from each other, is correct and/or good for a team? I've been on plenty of projects for different companies now where we are constantly adding and/or maintaining features on a product. There is no rest. We sprint, and then we sprint again, and then it continues on, supposedly forever. When we "slow down" to manage tech debt, we do it in a "Sprint". What the hell? Aren't we using the concept of a sprint incorrectly here? Can't we do a few sprints to get a core feature/product delivered and then do no sprints until we are really ready to take on the next big piece?

What do y'all think?

Answer 1

whether the notion that sprints/iterations in agile development should always be back-to-back

Yes. A Sprint is timeboxed, and the next sprint starts right after the previous one's timebox ends. This provides the cadence and rhythm of a Scrum sprint.

with only a review and planning meeting to separate them from each other

Reviews and Retrospectives are held at the end of a sprint. Sprint Planning is done at the beginning of a Sprint. These Scrum Events bookend the actual Sprint, as opposed to occurring 'in-between' Sprints.

There is no rest. We sprint, and then we sprint again, and then it continues on, supposedly forever. When we "slow down" to manage tech debt, we do it in a "Sprint".

Paying off technical debt is part of the Stories to be completed within the Sprint. Ideally, technical debt should not accrue very much if we do most of the XP practices (i.e.: test first, refactor mercilessly).

Of course in the real world, debt does accrue. A good strategy is to allot some time for refactoring while User Stories are being decomposed into subtasks. For example, a User Story from the Product Backlog is written such that the value to the business is stated, but as we decompose it into constituent tasks, we correctly estimate that existing code must be changed for our new feature to be integrated in. At the end of the Sprint, developers get their value in better code, and business gets their value in working software.

Can't we do a few sprints to get a core feature/product delivered and then do no sprints until we are really ready to take on the next big piece?

I would invite the development team to review their coding practices, if there may be some improvements so that quality can be built-in. Perhaps pair programming? Code reviews? Senior members taking more time to mentor others? Test-Driven-Design to minimize bugs and to make sure they are not over-designing/gold-plating?

How about the Sprint Retrospectives? Are team problems being raised and attempts at improvement being tried? Are Daily Scrum standups devolving into old-school Project Manager "status reports"? Does the Product Owner respect the Development team's decision regarding the capacity of Stories to be done in a Sprint?

There are a lot of possible ways Scrum can be tweaked to optimize performance. As long as the team keeps to Scrum's core pillars of Transparency (people are upfront with what's happening), Inspection (both work and the work process is being evaluated fairly but realistically), and Adaptation (doing something to improve a situation), each iteration should sort itself out eventually to a better one.

Further reading from the official Scrum Guide

Answer 2

A sprint is simply a collection of work (backlog items) to be done which provides some value to the product. It can be adding a new feature, it can be refactoring existing code to make it easier to maintain, fixing bugs, or anything in between. Each sprint is limited in time, usually to 1 to 4 weeks. There is a planning at the beginning and a demo / review at the end to distinguish one sprint from another, but otherwise they run one after the other.

If you did a couple of sprints to get a core feature developed and then did no sprints until you're ready to take on the next big feature, what would you do during that time?

If you are doing too much during your sprints (so you feel like you are always sprinting, rather than running a marathon), you may want to revisit how many story points you take in during each sprint; you may be doing too much. An occasional flurry of work may be OK, but it will quickly lead to burnout if it's the norm. You may also wish to change when your sprints begin and end - sprint planning on Monday and demo/review on Friday gives you a natural break between sprints.

Answer 3

This is a pretty common problem for developers in Agile Scrum, and here's the thing you're not going to want to hear: You cause your own burn out for the large part, since the work is on going, efforting low to help the company doesn't help either when somebody ends the relationship for whatever reason.

The other thing I'd like to mention is it might be helpful to approach the sprint as a pie chart of priorities, so you'd have 10% of the pie towards tech debt. Giving the sprint a theme may help too as far as goal setting to not make it as monotonous.

Or just switch to kanban, scrum doesn't fit all scenarios, it's especially a bit iffy on maintenance.

Answer 4

You're (presumably) working five days a week. Scrum is a way to manage work. So why not use scrum five days every week?

That's a bit facetious, but the fact is that if you think scrum is good enough for working on features, why don't you consider it good enough for working on everything else?

The Rhythm of Scrum

Part of what makes scrum work is that it puts your team into a rhythm: plan a little, work a little, re-evaluate, plan a little, work a little, re-evaluate, and so on. The rhythm itself is adding some small amount of business value, so it shouldn't be thrown away.

Taking a breather

If you feel like your team needs a rest, you can rest during a sprint. Just work with the product owner to fill a sprint with some easier tasks. There's nothing in the scrum guide to prevent you and the product owner from optimizing the backlog for a little breathing room now and then. Your team should still provide business value, of course -- companies don't pay employees to just goof off, you're there to do a job.

Watch for warning signs

All of that being said... if you feel your team needs a breather, maybe that's a signal that you're doing something wrong. Sprints shouldn't actually be a literal sprint. You shouldn't be working as hard as possible for the duration of the sprint. Your pace needs to be sustainable. If it's not, perhaps that needs to be brought up in the next retrospective.

Answer 5

There are frameworks that alter the cadence somewhat. For instance SAFe (scaled Agile Framework) uses the concept of Program Increments (PIs) which are a set of 4 sprints (usually 2 or 3 weeks), followed by a one week Innovation and Planning Iteration which sets aside time for developer training, planning for the next PI and other activities. It's sort of the best of both worlds. You get the cadence that makes scrum effective, but you get planned breaks at set intervals to keep things from feeling like a death march.

If you aren't or can't use something like that, I'd recommend something similar to the suggestion @Bryan Oakley had for pacing the work to avoid burnout.

First of all, avoid planning on 100% utilization at the start of the sprint. A good working number is 80% of your historic capacity. That's the number you give to the PO when planning. This leaves you time to be sick, for instance or work a customer service escalation if one arises. If you find you have time, you can always pull in additional work from the backlog.

Alternatively, you could craft an agreement with your Product Owner where a certain percentage of time is spent on tech debt or personal development. Where I've been we've used formulas like 15% to tech debt, 10% to personal development. It's easy to show these activities have business value even if they don't produce new working code.

Answer 6

It sounds to me like you're in an organization that is using "Sprint" as an exceptional state. Like, the ordinary cadence of development is more of a "lope" or "mosey", and some manager liked the sound of sprinting instead, and described it as a temporary speedup that then stayed around because it's producing more value.

That Isn't Scrum [TM]. In Scrum, a sprint can have as much work as the team commits to having in it, as negotiated with the Product Owner.

If the development team is feeling like a whipped mule running the Kentucky Derby, well, That Isn't Scrum either.