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.

This question already has an answer here:

My current team operates under the Scrum approach to agile development. We do it properly, adhering to the guidelines and roles of a Scrum team, with a sprint length of 9 days and a team of 7.

We go through the backlog in the grooming and planning meetings, estimating what we need to, negotiating with the product owner etc and come up with a sprint of a point size meeting our velocity. However, the problem is this: towards the end of the sprint (up to 2 or 3 days prior to the finish) some (not all) team members find they have little work to be doing whilst others are finishing off/working on tasks which can't easily/reasonably be worked on by more than the current number of developers. The usual result of this is pulling extra work in - but because we're nearing the end of the sprint, the work pulled in tends to be a series of bug fixes and small tasks which might usually occupy a single developer for a day.

My question is this: is running low on work toward the end of a sprint common? Is there anything which can be done to avoid it? Improve the situation?

share|improve this question

marked as duplicate by Dan Pichelman, Corbin March, GlenH7, Yusubov, MichaelT Sep 5 '13 at 3:34

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
Was this team producing software before they started using Scrum? Do you have an metrics from before and after that you could compare? Maybe even just a gut feeling? –  Ampt Sep 4 '13 at 20:45
    
The company was producing software prior to using Scrum, however my team was put together of new employees around the time of the company's adoption of an agile approach. When you say guy feeling, do you mean a gut feeling on metrics, or if its common to run low on work in the company? –  AndyBursh Sep 4 '13 at 20:58
1  
Related: programmers.stackexchange.com/questions/66708/… –  pdr Sep 4 '13 at 21:05
2  
It's better to run out of tasks and still have sprint time left than the reverse. –  Dan Pichelman Sep 4 '13 at 21:10
    
Why not just set a more optimistic target when this starts to happen? As for backlog, bonus is bonus. There's nothing wrong with getting some preliminary work done on an item likely to get slotted for the next sprint but not finishing it is there? –  Erik Reppen Sep 5 '13 at 0:30
add comment

1 Answer

up vote 11 down vote accepted

My team faces the same terrible problem: We always end up finishing our sprints ahead of schedule.

All joking aside it can be an indicator that something is wrong with estimation or expectations:

  • Are you consistently overestimating tasks and giving management a poor timeline of what to expect?
  • Do you have more developers than you need? (Shh, don't tell accounting.)
  • Or is your team really just that good that they consistently exceed expectations.

Deciding which of the above applies to you is up to you and your team and beyond the scope of the question, but the fact remains that if you are consistently getting done early, then your management is going to have an imperfect picture of what to expect from you. Either you can work on creating more accurate estimations, or management is going to just start expecting you to finish every sprint early. Finishing consistently early is almost as bad as finishing consistently late, but still not as good as getting it close every time.

As to what you should do is finish the sprint early and start on the next sprint right away. If you find that you're waiting to close the sprint up on a few tasks that only a couple people can do, then you're probably doing it wrong. Every person on the team should be able to do any task to a relative degree. If you have a Bus Factor of 1, something is wrong. Invest the time in your team to bring every member up to speed on the different aspects of the system, even if only for rare occurrences. You'll see that investment pay for itself when team members can talk about the project as a whole from top to bottom.

Try to break down these tasks that hold you back so that everyone can be working up until the tail end of the sprint. If you find that you can't break these tasks down, tackle them earlier so that everyone has something to work on, that way you can close the sprint early and start on the next one. Or, if your boss is cool with it you can always just take a few days off, but I'll let you figure out how to break that one to him.

share|improve this answer
    
Thanks for the excellent answer. I'm thinking it's a combination of your three bullets: I think we overestimate tasks (team disagrees with my estimates often - perhaps I underestimate?), have more developers than we strictly need (or aren't putting enough work in the sprint to accommodate that many) and we've improved as a team in a short space of time from failing to fulfil our initial velocity. However, I think some of this comes from management (understandably) not wanting to create a sprint we won't finish, and instead under filling it, with the intent of bringing more work in. –  AndyBursh Sep 4 '13 at 22:06
add comment

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