How can we reduce downtime at the end of an iteration?

Question

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?

Answer 1

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."

Examples:

• 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.

Answer 2

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?

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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."

Answer 7

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

Answer 8

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.

Answer 9

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.

Answer 10

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

Answer 11

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.

Answer 12

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.

Answer 13

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.