Is it appropriate to have a "clean up" sprint to start fresh without carry-over story points?

Question

Our Scrum team has been having incomplete (not accepted) stories at the end of a sprint (usually 3 week sprint durations) that carry over into the next sprint. This has happened in every sprint except one in the team's 30 sprints.

We have tried to reduce the number of new story points that we accept in the next sprint relevant to the amount of carry-over. We also consider whether the remaining work on the carry-over stories is development and QA/testing or just QA/testing to try to avoid creating a bottle-neck in an area, since we are not cross-functional.

The reasons for the carry-over can be things like receiving incorrect test data that has to go through multiple cycles and lengthy processes in other systems, or the instability of the QA/test environment.

We are thinking of having a "clean up" sprint, where we would only accept critical, "must have" stories in order to reduce the committed story points and allow time to catch up on and close out any carry-over stories. This would allow us to start the first sprint in our next release with a "clean plate."

Have other teams done this and is it effective? Should the duration of the "clean up" sprint remain consistent with previous sprints or be shorter (i.e. two weeks instead of our standard three)?

Answer 1

It looks like you aren't accounting for your velocity.

If you start with a sprint of 100 planning units, but only complete 90, your velocity is 90.

When you carry over 10 planning units, you should accept only 80 new planning units. That gives you a sprint of 90 planning units which matches your current velocity. If you find you are done before the scheduled end of the sprint, add more planning units to the following sprint.

If you carry over 10 planning units, and take on another 90 planning units, your sprint consists of 100 planning units. Based on the velocity of 90, you can expect to have 10 planning units of work left at the end of the spring.

Over time you will get a better idea of your velocity, and plan better. Expect variance in velocity between sprints. Planning units are estimates, not known quantities. With experience the estimates should get better and have lower variance.

Answer 2

A clean-up sprint is not entirely a bad idea, especially if things have gotten so bad, that you can't really take on any new work. However, in true Agile fashion, you should not need a cleanup sprint in the first place.

You need to address the elephant in the room here - if you are seeing the same issues popping up each sprint, then you (and moreso the team) need to do something about it. This will just demoralise the team further if they never realize their commitments. Remember the purpose of story points and sprint goals, it gives the team something realistic to aim for.

1. Inspect and adapt by utilizing the feedback in retrospectives - Are you holding retrospectives where the team have identified any of these issues?
2. Measure the time between states - Tools like JIRA help to show you the cycle time between the states of your user stories. For example, if a story spends 5 days in progress, but for 4 of those days the story was in QA then you clearly have a problem with QA

Answer 3

Most of this answer is theoretical. I've included what may be the crux of the issue at the end. But you should probably read the whole answer.

According to the Scrum Guide:

The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.”

So the first question: is the increment always releasable?

If not, why not?

If it is, what is this concept of "clean up"?

Whether or not the stakeholders and Product Owner agree that the changes in the Increment are what they wanted, they are there. It may be that the Product Owner does not want to release until a future Incremement is provided, but as long as it is releasable, the Product Owner should accept the increment. If not, then the Product Owner and Development Team should work out whether anything from this Increment is salvageable, and the Scrum Team (Product Owner + Scrum Master + Development Team) should work to understand how the Development Team didn't manage to deliver a releasable Increment. Not having a new Increment is far from ideal, but any wasted effort is restricted to one Sprint at most, and new insights and opportunities to improve will have been identified.

So the issue is really one of whether the Development Team have undone work in the Increment (e.g. newly broken functionality, or untested/undocumented features that are merged but don't meet the definition of "Done"), or whether they have unfinished work, which is that they have delivered some of the required feature(s), and the product functions in a way that is acceptable, but not as good as stakeholders hoped.

If undone, then the Increment is not releasable - treat as explained above. If unfinished, then assess what future changes are required/desired, and have the Product Owner add them to the appropriate place in the Product Backlog, then allow the Development Team to estimate the new items.

Just because there was some previous expectation of delivery, the Development Team must start and end the Sprint with a releasable Increment. Taking this Increment, the Development are only likely to be able to do a certain amount of work. Be empirical. Use previously gained knowledge to work out what can be done, and the Development Team should be able to forecast what it can deliver in the next Sprint (note: the Scrum Guide now refers to Development Teams forecasting, rather than committing - that's just being realistic). One Sprint that delivers less than forecast is not a reason to expect the next Sprint will deliver more. If something limited the team's ability to deliver a certain amount last Sprint, unless that issue has been identified and resolved, there's no reason to expect the team to deliver more the next time.

Whatever happened, use the Sprint Review in a way that enables the Scrum Team and Stakeholders to minimize the risk of this happening again. Use the Sprint Retrospective to establish new ways of working, and potentially a change to the definition of "Done" to minimize the risk of it happening again.

---

From your question, I actually think the real issue (which you would probably also identify from using Scrum strictly) is that your Development Team is not responsible for QA. Not all members of the Development Team need to have the same skills (they don't need to be a "Developer" as such). The team needs to be able to do everything that is required to produce a "Done", releasable Increment. The logical step might be updating the definition of "Done" to include QA, and including QA engineers within the Development Team, and potentially adjusting tooling/systems to support this way of working.

Answer 4

No.

This is a problem you can solve with versioning rather than project managment.

Carry the story(s) over into the next sprint and accept new stories as normal. But merge the 'clean up' stories into the previous version and the new stories into the new version, in the same way you would do a hotfix.

In this way you can 'complete' a version for release while using spare capacity on new features. Having two versions on the go at the same time will put presure on testing though, so be careful not to let it get out of hand

Answer 5

Recognizing when it's time to clean up and not take on any more is a good thing. Calling that a sprint is a weird thing.

Normally that's part of a sprint. I've worked in two week sprints, month long sprints and one week long sprints (I greatly prefer the week long sprints). Regardless of size I'm always very conservative with the work I take on. In a week long sprint I ask for what I think of as a day worth of work. I have to because I'm lucky if I get to spend a day's worth of work on any one thing in a week.

I always aim to have someone else looking at my stuff before the sprint ends. I try to give them a day (an actual day) at least. I try to leave a day for me to fix whatever they find and clean up the day after. If I blow that I'm coming in on the weekend. So why aren't I spending every weekend at work?

Here's the real trick. The moment you even suspect there's a chance you wont make the deadline you revise your estimate. You find some smaller amount of work that can be achieved, tested, cleaned up, and shipped before the end of the sprint. You drop anything that you won't be finishing to the backlog as soon as you can. Maybe you get to finish it later. Maybe someone else does. You don't hold on to work you won't finish on time.

If that means you're done on tuesday fine. Spend Wednesday researching, Thursday training, Friday planning what you'll do next sprint.

It shouldn't be cleaning up that gets moved to the next sprint. It's the second part of whatever problem you're trying to solve. A sprint really ends when you can prove you did something useful.

Answer 6

You're essentially talking about a constraint. The very nature of a constraint is that negatively impacts your total throughput. Think of a lunch counter with 5 seats. There's a line of people waiting around the block to each lunch and the first 5 take a seat and order. However, you have just one cook, who for the sake of argument, let's say can only cook one person's meal at a time. The cook is your constraint. Adding more seats at the counter will not do anything but make your problem worse, adding to the orders the cook already can't fulfill.

That may sound like an argument for your "clean-up sprint", but the problem is that it's not a permanent fix. Sure, the load on QA is reduced for a little while, but as the rest of your team ramps back up, suddenly they are behind again and missing targets again. The only real solution is to slow the entire pipeline down such that the constraint is no longer a constraint (stuff moves through the entire pipeline at a steady and consistent, if slow, pace), or remove the constraint, by adding better test tooling, more QA team members, etc.