Where I work we practice scrum-driven agile with 3-week iterations. Yes, it'd be nice if the iterations were shorter, but changing that isn't an option at the moment.

At the end of the iteration, I usually find that the last day goes very slowly. The actual work has already been completed and accepted. There are a couple meetings (the retrospective and the next iteration planning), but other than that not much is going on.

What sort of techniques can we as a team use to maintain momentum through the last day? Should we address defects? Get an early start on the next iteration's work anyway? Something else?

  • 3
    I vote for an early start. That is what we do.
    – Job
    Commented Apr 9, 2011 at 16:06
  • 15
    I vote for going home early. That's what I would do. Commented May 3, 2011 at 17:16
  • @Kirk 11 a.m. may be a bit too early. ;)
    – Adam Lear
    Commented May 3, 2011 at 17:17
  • If the retrospective only takes 1½ hours ((11am-8am)/2meetings), maybe you should make it more fun. :)
    – bzlm
    Commented Jan 21, 2012 at 14:37

13 Answers 13


I've been struggling with the same question a bit lately. We are starting on the next iteration, but I feel that this removes the satisfaction of an iteration well done.

I am thinking about the option of leaving it up to the developers, with the caveat "as long as the intent is to benefit the company."


  • Spend the day learning something
  • Spend it on an innovation time project
  • Spend it tidying up that annoying piece of code you never get around to refactoring
  • Have a good run through the app with a view to UX (which we never seem to find time to do otherwise)

Whatever motivates the programmer, giving them an incentive to deliver the release on time.

  • 15
    I like your first bullet "Spend the day learning something" in the long run this can have HUGE benefits for not just the developer but also the company.
    – Unkwntech
    Commented Apr 12, 2011 at 5:44
  • 1
    For an interesting take on something very much like your examples, fedex days (blogs.atlassian.com/rebelutionary/archives/000495.html) are a very interesting idea. Build whatever you want, but deliver it in 24 hrs. Commented Apr 12, 2011 at 15:51
  • Learning new things can be a huge morale boost. Just make sure it's in a sphere that's somewhat related to the company's business
    – user7433
    Commented Jul 5, 2013 at 17:01

Take the day off. You did the work you were supposed to get done so why are you still working?

If process change were possible, consider dropping iterations, release continually, and just keep pulling stories off the backlog. But don't you deserve a little down time?

  • 8
    Because believe me, when the sprints require you work late - you'll work late :)
    – Spedge
    Commented Apr 12, 2011 at 8:16

I have noticed the same issue (and we sometimes use 2-week sprints, which exacerbates it even more). What I try to do for those days (sprint review day and sprint planning day) is save up some work that I know I will want to do but doesn't require lots of planning or intrateam communication, like low-priority bugs, polish, or tools improvements. Sometimes this actually becomes a positive, as it creates a good time to do important but non-sexy work that it would otherwise be hard to make time for.


Even if our user stories is almost always finished by the end of an iteration, we always have a long list of "nice-to-haves" at the end, along with a list of known bugs. So when people finish of their stories there is always plenty to do.

I think that doing retrospective meeting is king, even if its mostly the same problems that is raised, it is very important to spend a bit of time pondering how the iteration went, how are you to learn, if you don't realise your mistakes and the things that went well.

If all bugs are done, a long list of things to be done better, has been done, along with action points, I think its nice to get the team together in front of a big screen, and try to play around with the software which was build, along with some beers. Its not hugely productive, but its nice to talk about what has been implemented, and how it actually works.

If you have days, then I would try to find something new to learn, and try to play around with it, maybe its the next big thing. But then again if there is days, then there is probably a user story in the backlog to do


Our iterations finish on Thursdays, to be able to fix any last-minute issue on Friday. But those Fridays (one every 2 weeks) coincide with our Beer Fridays, so we try to take it quite calmly. Fix some minor bugs, spend some time reading stuff (books, StackExchange, blogs, etc), and relax with a beer at the end of the day. Otherwise you don't reach a feeling of completion or closure, and instead feeling like a hamster spinning in a wheel non-stop.


I'm not sure you want to always finish exactly on time. Getting your work done a bit early allows you to think about future stories, capabilities and features. It gives you a bit of pause after a job well done that can be more rewarding than starting up early or committing to more stories and always having work carry over.

Ken Schwaber states in his blog http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

"God help us. People found ways to have slack in waterfall, to rest and be creative. With Lean and Kanban, those hiding places are removed. We now have a progressive death march without pause."

  • 2
    Exactly. The OP's post seems like the opposite of what it should be.. it's basically saying "How can we do more work after we finish early?" instead of saying "We finished early, let's relax a little bit." Commented May 3, 2011 at 20:29

On my projects, during the iteration planning we always select some extra tasks and label them the "bonus tasks" that get worked on if everything in the iteration gets finished. Pragmatically, these "bonus tasks" are generally what would be worked on first in the next iteration anyway, but pyschologically calling them "bonus tasks" works much better then simply always having more work planned then can be completed.

For other things such as learning or innovation time, we simply let each developer spend up to a day a week on that stuff as a normal expected thing. It can be any day of the week (i.e. it doesn't have to be at the end of each week).

  • Nice - whatever you call them it should be crystal clear that this is extra work undertaken. There is nothing more demoralising than having a sprint labelled as failed because the promised work wasn't completed.
    – Robbie Dee
    Commented Dec 6, 2016 at 13:12

All the developers in my team use the free time towards the end of a sprint (provided that all sprint tasks are finished) as 'Google time'.

This is where each developer works on his/her own idea/project as long as it benefits the company. I strongly suggest putting a system like this in place, this has really increased job satisfaction levels within our team.


If you are constantly finishing three days early, it suggests to me that you are not planning enough stories for the sprint.

One of the goals of scrum is to increase productivity - you won't do this if you are under shooting each sprint.

To solve this, plan more stories than you have been. Only commit to your previous velocity, but if you finish those stories start working on the extra ones. If you complete more, up your velocity for the next sprint. Always plan for a little more than you will commit to, or at least have some stories lined up, just in case.


This is one of the reasons we switched to Kanban. All the benefits of scrum without having to keep breaking off from the project.


I like Todd's answer of taking the day off, however i would say that try and do sprint planning and retrospective in the morning and set a challange of getting it done in time for lunch and then take a long lunch as a team. At the lunch encourage discussion about the sprint so you get an informal retrospective for free.

If you can't then give the aftenoon off (and i mean as in go home early afternoon off not a set your own objectives afternoon off) then address technical debt as it is the one thing that depresses a developer more than anything else (source: my opinion) having to work around technical debt when they know exactly how to address it and make their life easier.


I personally find that retrospectives are not really worth spending time over, there are usually a few common recurring themes (poor user stories, bad estimation, etc) and you just accept these as problem areas and move on. We also try and deal with problems as/when they arise, rather than waiting for the retrospective (which we had a tendency to do in the early stages of adopting Scrum).

Now instead of having a retrospective, each pair of developers picks an outstanding item from the existing retrospective backlog and works on it.

We also keep an ongoing technical debt backlog, which acts as bonus items for sprints (if the business aren't ready to implement something from their backlog ahead of time).

This has already proved quite positive, in that all the niggly little items that just keep bubbling under get a day's worth of attention each sprint.

  • How long did it take you to drop the common retrospective issues (poor stories, estimation)? Do you never do a retrospective, moving all the discussion into smaller discussions throughout the whole sprint?
    – cringe
    Commented May 5, 2011 at 18:50

Have a white-board design session and share implementation ideas for interesting stories on the upcoming sprint. Do this after and separate from the planning session, where stories were still light on details and judged by story-points or t-shirt size estimates. Keep the session informal and encourage creativity.

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