11

What to do when a sprint is finished early?

At the moment our Scrum team works off stories from the backlog, if the sprint is finished early.

What happens with stories taken from the backlog? Will the stories be added to the current Sprint ? If yes, what if these stories won't be finished in time. Is the Sprint failed then?

  • 3
    Are we talking a day? (in which case, this applies: programmers.stackexchange.com/questions/66708/…) or are we talking a week? (in which case branch/tag and start on the next iteration) – pdr Dec 12 '12 at 16:08
  • 4
    Sprints don't "fail". You may not complete the number of story points you set out too which just means you adjust your expected velocity next sprint. – Martin York Dec 12 '12 at 16:30
  • 2
    Go on a holiday! – Dipan Mehta Dec 13 '12 at 8:14
  • Have an early shower :-). – Stephen C Dec 13 '12 at 11:28
  • Same thing you do when your code's compiling: xkcd.com/303 – Paul D. Waite Dec 20 '12 at 16:21
17

Bring something from the project backlog into the sprint (after discussions with scrum master and project owner).

The size of the item you undertake will depend on how much time you have. If there is nothing small enough create a sub-task of a bigger task to get it started (ie do some of the preliminary work).

Alternatively create some tasks that make the code base better. I have never seen a code base that could not be improved in some way. Review some code add more unit tests etc..

| improve this answer | |
  • I think the discussion needs to be more with the team than the scrum master. The scrum master can offer advice, but the decision of what to do belongs with the team. – Bryan Oakley Jun 5 at 18:30
  • RIght, but if the sprint is finished, that implies the whole team is done. The question wasn't about when an individual is finished, but rather when the team is finished. This is a team problem, not an individual problem. – Bryan Oakley Jun 5 at 18:36
  • I understand what you're saying, but the scrum master should have no say in what gets developed next. That's up to the PO and scrum team. The extra work wouldn't blow up the sprint because the planned work has already been completed. – Bryan Oakley Jun 5 at 18:49
  • @BryanOakley Fare comment. – Martin York Jun 5 at 19:09
7

Working on stretch or future sprint backlog items seems to be the common thing to do, which makes a lot of sense if your sprint backlog items are small enough and clearly defined. However, backlog items that may place the "done" code into a "no longer done" state should be avoided.

If the sprint is truly finished, tag it, prepare it for delivery, deliver it, and put your source code repositories into the "next sprint" state so there's no risk that late sprint changes will put delivery at risk.

| improve this answer | |
  • I think if the sprint has truly finished early, they've already tagged it, prepared it for delivery, and possibly delivered it. The question is about what to do after you've already done all that and still have time left. – Bryan Oakley Jun 5 at 18:32
5

For us a Sprint never ends early. We only increased our velocity or solved the problem in a way that makes us get more work done in the sprint.

Saying that we always have a backlog of items that are prioritized in order of importance by our product owners. When any team can fit more work into the sprint it is very easy for them to see what to do next on the list that will fit positively into the sprints remaining time given their velocity.

This avoids any downtime by the group waiting for discussions with Product Owner/Scrum Master on what should be done next. Our Product Owners and Scrum Masters keep on top of this list so there is always more work waiting to be put into the next sprint (or current one if time allowed.)

| improve this answer | |
4

What my team does is pull tasks in from the backlog that are reasonably small enough to complete with respect to how early we finished. If we're done with that, we give our QA team time to catch up with their testing, and the developers get a "free day" - we can use this to look into other issues not related to the current sprint, topics we want to research, configure/reconfigure our environments, etc.

Don't put a whole ton of work in just because you've finished early. Stick to what your team has committed to do in this sprint, and if extra work gets finished, that's an awesome plus.

| improve this answer | |
3

I'd encourage slack to be used for personal improvement. Sure, pull in stories from the backlog, but make sure you spend some time on yourselves: learn a new language, practice your craft with a kata, refactor some stuff, tweak, refine or write new tools to help you out, go and talk to a stakeholder, colleague or client, find out what your QA team does, take time to understand how your UX process works.

There is a huge list of things you can do that will provide value to your business and yourself AND improve your velocity or the amount of quality value you provide that don't involve pulling things from a backlog, try those first.

| improve this answer | |
1

Sprints do not address products but periods. If a sprint lasts two weeks, it cannot finish earlier.

If the products planned for the sprint have been finished in advance (I think your question goes in such direction), nice. But that doesn't mean that the sprint is finished. Get your backlog and follow on.

In fact, a good scrum master would experience this situation almost half of the sprints. This should not be exceptional.

The end of the sprint is just a period to look back, understand what happened, assess the lessons learned, and make a new plan for the next sprint, based on this fresh experience.

If your team advances quickly, you have two things to do. First, give them more work, because they need something to do. Second, and the most important move: see how to reward them if they do deserve a reward (naturally, a single sprint is not enough, but if they keep the pace along some time). If they're good, you don't want to separate them. You don't want the members to leave. You need the company to recognize the effort and react in consequence. You should make some noise about them being good. You need the stockholders to know them. A highly productive team is not easy to gather.

| improve this answer | |
0

Thought I would expand upon some of the other answers here. Personally I think that adding to an active sprint is a very bad idea.

Scrum is all about the team committing to finish a scope of work that is set in stone. The team commits to that work in the planning before the sprint begins.

During the sprint, the team should be kept distraction free to focus entirely on implementing their commitment.

For those who disagree, has one read the original Jeff Sutherland Scrum bible?

With this in mind, let’s review why adding to the sprint might be a bad idea.


Firstly, it encourages individuals to increase scope without first consulting the team as a whole.

Everyone took part in planning and committed to the work. This takes a lot of time and effort. So, similarly, adding any additional work means that the team should review this and commit.

This is obviously hassle during the sprint. Individuals consult the product owner and discussions ensue. Perhaps there are several candidates to add as the backlog is not quite ready. After all, it doesn’t need to be ready as there’s an active sprint in progress and this was unexpected.

Disagreements about what to add and priorities of non sprint work then becomes a major distraction.


OK what about if all work is finished?

In my lifetime in working in Scrum, I can honestly say I’ve never heard a question about adding to the sprint, opened the Scrum board, and seen a board with all work done. It’s always a busy board with lots of work in progress!

What this question highlights are two things:

  1. the individual and possibly the team needs Scrum training
  2. the team has underlying issues around collaboration

Typically the individual is not collaborating. They have finished their work and they are looking for a new individual task. This should not happen in Scrum if there is any unfinished tasks.

Instead, the individual should be collaborating with others, working as a team to finish each task in turn. That collaboration and teamwork is the essence of Scrum! An individual "running out of work” or “with nothing to do” should never happen. The Scrum team will run out of work when the sprint ends.


Temptation, temptation, temptation!

Because it’s a lot of bother to discuss what new work to add, and there exists a culture of adding more tasks to the sprint, it’s very tempting to simply drag new work in without consulting anyone.

This is a very dangerous practice. Perhaps the individual chats to the product owner, agrees some priority, adds the work and assigns to themselves.

It can be an unpleasant surprise for team mates to see the scope of work increase. The Scrum Master then faces additional headaches in “policing” the sprint backlog.


It Distorts The Burn Down Charts

The hint is in the name; Burn Down. That is down not up. The Burn Down chart should never burn up. If this chart is burning up then the Scrum team should carefully consider the issues presented above.


The Solution

So, what’s the solution? Well thankfully there is a very simply and easy solution. That is, simply finish the sprint early! This avoids all the issues mentioned above. The team can review the early finish during the retrospective and commit to more story points in the subsequent sprint. Over time they will refine and at some point will finish on the final day as intended.

This will be much easier if they are distraction free to focus entirely on their commitment.

If in the early days of the Scrum team, they finish a few days early. So what? They still continue working and picking top priorities off the backlog. It’s not a problem to worry about because the team accuracy will increase and this problem will go away.

—————

Final Thoughts

Teams that add to sprint backlogs, work individually and so on, really need to introspect. Do they consider themselves a Scrum team? What is a Scrum team? The answers maybe quite revealing. There may be confusion as to what is Scrum. Moreover it maybe that the team does not want to be a Scrum team once they really understand what that means. That’s ok! There are other approaches and some may work much better. It’s all good.

| improve this answer | |
  • After reading this answer, your position is unclear to me. You seem to mostly be advocating for doing nothing if the team finishes early. yet you then have one sentence that says "They still continue working and picking top priorities off the backlog.". At the end of the day, if a team finishes early, what is your position: do nothing, or continue to pick items off the backlog? – Bryan Oakley Jun 5 at 18:28
  • team should never do nothing. On finishing early they should continue to work but in a more relaxed and perhaps even less collaborative manner. Maybe even catch up on some admin, training, or start grooming some features for the subsequent sprint. The Scrum daily should be suspended until the start of the subsequent sprint. – Max MacLeod Jun 8 at 8:48

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