We are running 2 weeks sprints where the team will just barely finish development by the last day of the sprint but cards are not complete because testing is not finished. The definition of done is really "when development is complete" rather than "when the stories are complete." We have a 1 week delay between the last day of the sprint and the release date. The team does finish the sprint by the release date but that seems like that isn't quite meeting the objective of scrum. The team starts the next sprint the day after the previous sprint ends.

I see the following problems:

  1. team is not using whole team testing
  2. team is not too interested in pair programming or piling on one card at a time.
  3. Maybe the stories are too large and we should break them down more so that we finish at a more steady pace throughout the sprint?

Any suggestions on how we get the team bought in to finishing the sprint by the end date? Or other ideas?

Why do we think it is important to finish by the last day? Why does it matter if the team is still finishing by the release date? (I have my own answers but am curious what others think here.)

  • 4
    wow. Two things. 1) Done means done. Done coding, testing, ready for prod. Revisit what you consider "done." 2) To answer your title question, it's always important to estimate well. Your teams are NOT working on new stories if they are still fixing the previous sprint prior to release. Your estimates will never be right if you are always working on things from the previous sprint.
    – Steve Miskiewicz
    Apr 19, 2012 at 3:13
  • adjust how many new stories you are taking on in new sprints to reflect how many you did last time. and yes done needs to mean done else you are just lying to your selves.
    – jk.
    Apr 19, 2012 at 12:51
  • So, you call software done before it has been tested? There's your problem right there. Apr 19, 2012 at 23:45
  • untested code is not "done" - It's a bomb waiting to go off. Jul 9, 2015 at 8:53
  • @user1342613, Did any of the information provided here on programmers.stackexchange end up assisting you? Are you still around?
    – David
    Jul 13, 2015 at 23:03

3 Answers 3


The need of Scrum isn't to complete every story at the end of every sprint. In fact, that might not happen, especially early in a project when you are still settling on a velocity. The idea is to have a potentially shippable (working, tested, and documented) product that adds business value to the customer at the end of every iteration.

The first thing to do is to improve your definition of done. Done should mean that the story is complete. That means it has been designed, implemented, unit tested, integrated and passed system and acceptance tests. When a story is done, that means the feature or capability that the store represents is ready for delivery to the customer. The Scrum Alliance has some articles on what a good definition of done looks like, how to know when you are done with a story, and a methodology for creating a good definition of done.

Next, you should probably begin to work on your estimation and planning. It shouldn't be a continual struggle to incorporate the stories into each release. It begins with having appropriate and accurate estimates as to the size of the story, which often uses story points to provide an estimation of the relative effort required to complete the story. Once you have estimates, you need to use these estimates to plan. If you find yourself finishing 10 story points every sprint, don't pull more than 10 story points into the next sprint. If you pulled 10 story points into one sprint, but only finished 8 of them, only include 8 in the next sprint. If you finish early, you can either pull in more story points or use the additional time to reduce technical debt by refactoring, writing new automated tests, or improving existing tests (as a few examples).

Rather than starting the next sprint immediately, make sure you have time for your retrospective and planning meetings. Use this as an opportunity to determine what was problematic or needs improvement, and then implement corrections for the process in future sprints.

I think that doing this will resolve some of your problems, and make others easier to fix, or at least bring out more information. Some of the problems are also related to organizational culture, such as the entire team participating in testing or not using pair programming. Eventually, you are going to want to get the entire team into testing (and other activities), since Scrum is centered around a team that has cross-functional skills. Improved estimation will also help you identify if your stories are too large. As far as pair programming - it's a non-issue, since it's not required for Scrum and might not be of use to your team.


Where I used to work, we'd have a code freeze to allow time for testing in the sprint. This also would give developers time to do refactoring and other minor tweaks while QA reviewed the work done to see what is and isn't ready for production as the refactoring work wouldn't be merged until after the release was tagged/branched.

I'd question how well does the team understand the idea of velocity where X points of story work are done in a sprint and not bleeding into another sprint with bug fixes or other work that would impact the next sprint's work.


Any suggestions on how we get the team bought in to finishing the sprint by the end date?

Strictly speaking, the Sprint is finished by the end date, whether the Sprint Team has completed all the Sprint Backlog items or not. You don't need "buy-in" to finish the Sprint on time... You need "buy-in" to actually follow Scrum.

Why do we think it is important to finish by the last day?

Why does it matter if the team is still finishing by the release date?

Another part of Scrum is your "definition of 'done'". The definition of "done" that you have chosen (development complete, but not testing, etc) does not allow you to achieve the main goal of Scrum ..."a high quality increment of a deliverable product".

Your Answer

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