We know that during every sprint, the team's primary goal is to achieve 100% completion of user stories which are part of the sprint backlog. But what happens in practice is that, development should be completed 2-3 days prior to sprint end, so that ample time can be spent to complete testing tasks.

Now, due to pressure of completing all user stories, the team can't pull another one since they know they will not able to complete it. Which means, either developers have to analyze next sprint tasks (which still may leave some spare time) or have to sit idle.

Some people may argue that planning was not good. But aren't we following Agile, where estimates may vary from actual (which leads to carry over of user stories) or maybe the scrum team completes all user stories in less time as compared to original plan.

Suppose the team is pulling another user story and didn't complete it. There is argument, it doesn't look good from management perspective that user stories are getting carried over.

Isn't the pressure of completing all user stories, which are pulled in a sprint, somehow decreasing the productivity of the team?

  • 1
    Hi Anoop, I have done some minor editing to your question to make it a bit clear. You may review and edit it again if you want. One clarification I would like to know is, I assume you mean pulling another user story which is not part of current sprint, when you wrote this "Suppose team is pulling another user story and didn't complete it", please confirm. Thanks. Jan 31, 2014 at 8:13
  • 1
    I'm a little confused about your statement regarding "testing task" that are (only) done after all other work has been completed. Testing should really be part of your Definition of Done. If some code is not tested, the respective story is not yet completed! (Adding this as a comment, since it's not part of the actual question)
    – Sven Amann
    Jan 31, 2014 at 8:42
  • @AzizShaikh , It's looks more clear. thanks.
    – Anoop
    Jan 31, 2014 at 12:43
  • @salsolatragus, Yes, after final testing we can say a US is completed. but in we know that testing also required much time/effort as development and probably bug may be found. Still during the testing time what developer will do if there is no other US is there in sprint.
    – Anoop
    Jan 31, 2014 at 12:46
  • 1
    You should focus on meeting the Sprint Goal, rather than on percentages of completion or utilization.
    – Todd A. Jacobs
    Jan 31, 2014 at 21:59

6 Answers 6


100% user story completion vs 100% productivity

Think in terms of value delivered vs utilization. Goal of Scrum team should be to maximize output and not maximize utilization. Anything (whether a machine or person) working on 100% capacity for longer duration will eventually break.

The goal of Scrum is not to achieve the highest resource utilization; it is to achieve the highest throughput of completed, deliverable value.

Article - The Case of the Time Tyrant (2008)

Full utilization concept may fit well in the traditional project management domain. However, software development is usually not a predictable / well-defined process, it is more of an empirical process in which you may end up in a situation where you have to discard a full days worth of work and restart from scratch. People have to attend meetings, answer to support calls, etc. in addition to writing code. So it may happen that a story gets completed earlier than estimated (or may get delayed too).

Maximum utilization can be counter productive

You should push back on 100% utilization part because maximum utilization can be counter productive in software development.

Scrum is about transparency and setting correct expectations. Stakeholders need to know when a particular piece of value will be delivered instead of how many hours of a developer were spent to complete a story.

What to do if you find idle time

I agree with the fact that sprint backlog should be completed some time before the sprint end date so that it can be tested and team can finalize a stable build after the required bugfixing etc. So developers may fix issues which were reported during testing within the current sprint. In case the team consistently performs well on the QA front and not many bugs come up then you may reduce this sprint end testing time and in future sprints the team may add more stories to the sprint backlog.

In cases where the team finds some idle time, the team may consult Product Owner to pick a story from product backlog which is next in line or can be completed in the remaining sprint time. Alternatively, if there are technical debts to pay then the team can also work on those.

In case of stories being carried over to future sprints, the Scrum team should not be held responsible for stories which were not part of the sprint backlog to begin with.

  • Sounds reasonable for throughput.
    – Anoop
    Feb 1, 2014 at 6:27
  • 1
    completed some time before the sprint end date so that it can be tested - er, isn't testing part of development? Apr 8, 2015 at 8:37
  • @JBRWilkinson I agree with your comment, testing is a part of development. I meant to say that coding gets completed so the story can be tested to mark it as Done before the sprint end. Apr 8, 2015 at 9:22
  • 1
    scrum alliance has removed their member submitted articles so to get to that linked article you'll need the wayback machine. The archived link is at the case of the time tyrant Jun 12, 2020 at 10:36

If you follow the Scrum framework strictly, you will not change a sprint's backlog after the planning. This means you will not pull another story. Free time at the end of the sprint can be used for minor refactoring, reading about technologies, optimizing you work environment, exploring new tools, and so on. There's always something to do, if you look closely.

This doesn't mean that you should finish every week after 4 days. If you (i.e., the team?) start feeling that you really don't have enough work, you should start pulling more work in the planning. If there's still space left and the next story is too big: break it down; pull the first part. The agile trick to productivity is to break stories down. Only when they are small enough, you can really measure your velocity.

Another thing: you are not going to hell because a story doesn't get completed. It's something that happens, as you cannot predict everything. If it happens you should analyze the reasons. Unpredicted problems? Maybe invest more in analysis next time. Too much work pulled? Adjust your velocity.

In any case: bring this up in the next retrospective. Discuss it with the whole team.


Your question seems to boil down to: "I have developers sitting around doing nothing for the last couple days of each sprint. What should I do?"

  1. Have the developers help with the testing. It's a cross-functional team. Sure, the developers might not be experienced testers: so give the testers the exploratory testing, and give the scut work to the developers. This will help motivate them for point #2 below.

  2. Have the developers help automate the testing (if you're spending 2-3 days testing a sprint's worth of stories, I'm guessing at least half of that could be automated, either as acceptance tests or as unit tests).

  3. Get testers, developers, and the product owner together to create acceptance tests for stories at the beginning of the sprint. Unless a story involves some wholly new interface, you can probably write or reuse fixtures to test it before it's coded.

  4. Don't call stories "Done" before they're tested. Go over your definition of "Done" to make sure it's what you want (or need).

  5. Find useful uses for the slack time: setting up or improving Continuous Integration, automating deployment, doing coding katas. If a bug is found, switch to fixing it.

Yours is a nice problem to have. Don't blow your opportunities by pulling in more work than you can do.


If one more story can not be started 2-3 days prior to the sprint end, it is too large. Smaller stories can be started later and will reduce your productivity issue.


The first problem with your team's approach is that tests shouldn't be done after code completion. You should apply TDD or test-first approach especially if you're using agile methodologies. Developing and designing unit tests, system tests, acceptance tests before starting to write code etc should be implemented in various stages of the sprint by pairing testers, developers and even analysts and UX designers.

Developers don't sit on their hands after completing their development tasks. They still have tasks which depend on code completion like technical documentation, UX modifications and of course modifications to the code which could be found by various kinds of tests (exploratory tests, installation tests, integration tests etc) after the code completion.


The goal of the team should be to complete 100% user stories at the end of Sprints. If they couldn't complete the user stories then there some mistakes in your estimations.

To avoid such things, when you call for Sprint Planning Meetings, explain the requirements to your team. Team includes devs, testers, designers, dba, etc. Then ask your team to estimate the effort required to complete each user story. In this way you can get an idea of time required to complete each tasks.

Business Analyst and Product Owner should prioritize the user stories according to business needs. Then take up the stories that can be completed in a particular Sprint. In this way you are not setting up unrealistic estimations on your team and your team can deliver 100% user stories and your management team will be happy with the results (which will never happen because they always expect more :P )

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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