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?

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..

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.

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.)

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.

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.

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.

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:

the individual and possibly the team needs Scrum training
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.

Filed under: softwareengineering - @ 13:28

Thẻ: scrum, sprint

Thiết kế website giá rẻ

Danh mục

What to do when a sprint is finished early?