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,733
Andy Hunt
  • 6,046

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,733