10

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?

Ampt
  • 4,605
  • 2
  • 23
  • 45
Andy Hunt
  • 5,996
  • 1
  • 33
  • 56
  • 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 04 '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? – Andy Hunt Sep 04 '13 at 20:58
  • 1
    Related: http://programmers.stackexchange.com/questions/66708/how-can-we-reduce-downtime-at-the-end-of-an-iteration – pdr Sep 04 '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 04 '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 05 '13 at 00:30

1 Answers1

13

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.

Ampt
  • 4,605
  • 2
  • 23
  • 45
  • 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. – Andy Hunt Sep 04 '13 at 22:06
  • In particular, if you have one developer finished and another developer finishing off a task that only they can do, then the problem solves itself. Pair them for the day. Now they're both familiar with whatever it is. Bus factor drops when everyone is "too busy with their own stuff" to share information, which is very bad. Having time to share information is not a problem! – Steve Jessop Jun 04 '15 at 23:15