1

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)?

  • 2
    Have you or are you doing things to address the root causes? Figure out why you're receiving incorrect test data and working toward getting the right test data when you need it. Figure out why your test environment is unstable and make it stable. These should be coming up in your retrospectives, so what is being done to address these problems? – Thomas Owens Aug 12 '16 at 19:55
  • Do you mean you have stories from sprint 1 still in sprint 30, or do you only carry over like one story for one sprint? – nvoigt Aug 13 '16 at 9:56
  • @Thomas Owens - we are trying to address the root causes by requesting the test data earlier, but in each case the requirements for the test data vary so it is not a repeated process. Re: instability of test environment - we share QA w/several other teams/applications so need to consider their needs as well. There are many systems and processes run in production. Keeping data in QA up-to-date would require on-going time and resources. We've escalated but I think it's going to take some time to resolve. – Bheitzer Aug 15 '16 at 11:16
  • @nvoigt - No, we haven't carried them over that far. Usually from one sprint to the next. But it is more than one story. Sometimes as much as 33 story points. – Bheitzer Aug 15 '16 at 11:18
3

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.

  • I like and understand your comment. We have tried this - to some degree - but it seems that some team members run out of things to work on before the sprint is over. We may have 25 carry over points that are all in testing and defect resolution. I hesitate to add more stories mid-sprint because that also adds to the testers' work load. Should the "clean up" sprint keep our 3 week duration and include adjusted velocity points and carry-over and if members run out of work, they fill time with code reviews, tech debt, training, etc.? – Bheitzer Aug 15 '16 at 11:34
  • @Bheitzer If some members run out of work before others, then you may have a task breakdown issue. Try to aim for tasks that take no more than a day. If you have defects from testing in carry-over, then you may want to look at your definition of done and your testing process. Get your developers to automate the tests, give priority to tests that fail. – BillThor Aug 15 '16 at 12:08
  • Yes, the task breakdown may be an area we need to focus on. The estimates may be for 3-4 hours but the task lingers in the Development status for 3-4 days. We do run automated tests on each release (a release usually includes 2-3 sprints) but these cover the more routine, predictable functionality. Testing our new features usually requires specific test users to cover various scenarios (i.e. online banking customer with Spending, Overdraft and Savings accounts with 3 months of direct deposit values). We're getting developers more involved in testing too. – Bheitzer Aug 15 '16 at 12:30
  • "...t it seems that some team members run out of things to work on before the sprint is over" : that is not much of a problem in Scrum. The goal is to optimize for the team, not the individual. You shouldn't have someone on the team with nothing to do until everyone has nothing to do. There is always something to do - testing, documenting, etc. – Bryan Oakley Jun 6 '17 at 20:08
1

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
1

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.

0

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

0

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.

  • Can you clarify what you mean by "you revise your estimate. You find some smaller amount of work..."? Do you mean that you add a new smaller story to the sprint in progress? What usually happens for us is we finish the carry-over stories and most of the rest of the stories in the sprint, but not all. I would suggest swarming on the remaining stories but with test data and QA env. issues that doesn't help. – Bheitzer Aug 15 '16 at 11:24
  • @Bheitzer revised – candied_orange Aug 15 '16 at 11:28
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.