Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

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

13 Answers

up vote 62 down vote accepted

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.

share|improve this answer
11  
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 Apr 12 '11 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. –  Steve Evers Apr 12 '11 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 –  omouse Jul 5 '13 at 17:01
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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

share|improve this answer
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." –  Wayne M May 3 '11 at 20:29
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

If you are constantly finished three days early, it suggests to me that you are not planning enough sorties 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 sorties 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 sorties lined up, just in case.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
    
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 May 5 '11 at 18:50
add comment

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.

share|improve this answer
add comment

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?

share|improve this answer
1  
+1 for "release continually" –  David Apr 12 '11 at 6:55
8  
Because believe me, when the sprints require you work late - you'll work late :) –  Spedge Apr 12 '11 at 8:16
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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