tags:

views:

117

answers:

7

Given that the tasks in a specific sprint will not divide perfectly into the team, and all finish on the same date, what do you do to keep everyone working as the sprint moves into its final stages?

Inevitably it seems like there will be one or two people freed-up. If all the other tasks are done-done, and the remaining tasks are already underway, then what?

Do those team-members pick up items from the top of the product backlog, as they are likely to be needed in the next sprint anyways to get a head start?

What do you or your teams do?

A: 

One thing I recommend is looking up future tasks and doing some detailed planning for estimates. This is non trivial and will take some time. Another is to scope of a new large scale project that can be broken into tasks and entered in product backlog.

omermuhammed
+7  A: 

My teams have always picked items up from the backlog, starting with the highest-priority items that can fit in the remaining time.

If nothing quite fits that criteria (as when there's only half a day left and/or no small stories to pick up), consider paying down some technical debt.

Jeff Sternal
+4  A: 

Scrum is done by teams.

If some people are done, they can help other members of their team.

They can also help their team by getting a head start on the next sprint.

They can also do some exploration of new technology, if that would help the team.

Or they could brush up their own skills, if that would help the team.

They could create training materials to help other members of the team improve their skills.

That's a team decision.

S.Lott
A: 

Refactoring, writing unit-tests, improvement skills.

Roman
+2  A: 
  • Pay down Technical Debt
  • Do anything that the team thinks should be done but doesn't belong on a card because there's no visible business value. Some people have called these tasks "technical stories". They tend to be things you should have done before Sprint 0, but didn't. Examples include adding of these that you don't already have to the build:
JeffH
+1 I totally agree. It's very hard to pay down technical debt in a running sprint as long as you're still working on the user stories. Focus is always on getting the stories done and paying off technical debt is sometimes hard to communicate to non-technical stakeholders. If you have additional time and you can use it to get to a these things, you should absolutely do so.
Anne Schuessler
A: 

(...) what do you do to keep everyone working as the sprint moves into its final stages?

Nothing, I expect a self-organized team to find out this by themselves. And there are many options (by order of importance):

  1. Help other members of the team to finish their stories (achieving the goal of the sprint is the most important, the whole team succeed or fail at this, not individuals).
  2. Prepare a kick-ass demo.
  3. Pick up a story from the backlog that can be done-done before the end of the sprint (i.e. not always the next highest priority items but something that fit in terms of size).
  4. Repay technical debt if you have some.
  5. Document things if this make sense.
  6. Explore new things (tools, frameworks, testing techniques, etc) that may be useful for the team.
Pascal Thivent
A: 

While it may seem obvious for team members to move on to the next highest items in the product backlog, I would advise against starting with this.

First and foremost, the teams' obligation is to achieving the sprint goal, so anything they can do to work towards that must come first (e.g. helping out testing, chipping in where possible, etc.).

Next, the team should look at expanding their definition of "done". Perhaps it currently doesn't include testing, or doesn't include some form of code review. Most teams starting with Scrum do not start with a definition of done that truly has a product increment that is ready to ship, so now would be the team to move towards that.

As others have mentioned, what tools do you need setup in order to get closer to a shippable state? Continuous integration? Automated acceptance tests? Now is the time to add these things.

Likely, you also have areas of the code that existed before you moved to Scrum and thus don't have very good test coverage or have accumulated technical debt. Now's the time to pay that off.

Also, as Mike Cohn suggests in his book Succeeding with Agile teams may want to reserve roughly 10% of their time for some look ahead planning. This may involve having a meeting with the Product Owner to discuss some up and coming stories for future sprints, breaking down larger stories into smaller ones, or for designers, perhaps doing some wire frames or mock-ups for upcoming stories.

Once you've gotten to this state, only then should you consider continuing on with the product backlog.

Todd Charron