What to do if the team is finishing the sprint to early?

Be warned. Until now we failed to implement scrum so my opinions are purely theoretical. :-)

The problem with the velocity is, that your "real" velocity is higher than the number of points you had in the sprint, because you could have achived more. So if you plan the next sprint based on that number you will have not enough points in it and probably finish it to early, too. So I think your Scrum Master is correct.

The problem of "refill" or adding items to the running sprint is (albeit other problems) a psychological one. It destroys the feeling for "achiving the goal" and could lead to a kind of "Sisyphos" syndrome and surely demotivates the team to try to finish work to early next time.
I think it would be best (don't know if it is "good" scrum) to finish the sprint early and start the next and take into account that the velocity is actually a little bit higher, than the numbers tell you. Perhaps you could add some percentaged number based on the percentage of time you spent, but I think a rule of thumb will do either.

> Our Scrum Master tends "to replan" when we have the possibility to attach the new stories
> for the rest of the time to the current sprint.

That's good, and I hope he or she involves the rest of the Scrum Team. Continual replanning is good in Scrum. However, changing a Sprint Goal is not.

> But we are running into the danger to "destroy" successfully completed sprint if we are not
> finishing the new stories.

Nonsense. The Sprint Goal has been achieved. The problem seems to be one of underestimation and the reasons behind this should be explored in your next retrospective.

> I think it would be best (don't know if it is "good" scrum) to finish the sprint early and start the next

No, the Sprint must complete it's timebox. Replan and consider bringing work forward with the approval of the product owner, or paying back some technical debt or doing backlog grooming.

I'd pull in more stories. The backlog should be groomed enough that the team is already familiar enough with the functionality to begin (and learn more as they delve into it).

The answer also depends on if you're deploying every sprint. If so, I could see potential danger in adding more, not completing them and not having a "ready for prod" product at the end of the sprint. If that's the case, I could see an argument for ending the sprint early. Even then, if you can have those incomplete stories still in a deployable state, I think its better to keep the sprints at the same rhythm.

Why only deploy at the end of the sprint? Why only deploy once a sprint or less? Why not a few times a sprint?

Everything has to be tested before it can go live. We can't push individual stories in our deployment setup, so we can't deploy until everything started is Done.

We fixed this with our branching model and can start in the sprint with next release features, and are still able to release the old version or make bugfixes in it to work immediatly on the feedback we get

The SM is correct to try to add.

However, keep in mind the following:
1. your committment for the sprint has been satisfied. whatever you add is "bonus".
2. unless you are delivering to actual production each sprint (not a good system, because it puts gratuituous pressure on the commitment), it doesn't really matter if you finish your addition (all that matters is that there is no idle time).
3. you should be easily capable of adding something realistic (eg: look at your story point burndown for the sprint and compare that against the remaining time to see which story to add).

If you do that, then the PO will be able to safely adjust the team's velocity.

Hello,
no, no no. SM is not correct an should read the scrum guide. Its not the task of the SM to add, but to help the team to learn and do good work.
In this case it is the team who have to decide what to do. The work is done. They can make a party, play silly games, may doing some further education, may doing some refactorings or ask the PO if there is something useful to do. They may pull, but nobody outside the team may push

It is completely up to the Dev Team to decide how much work to take on in a sprint, and this includes the ownership of deciding when to take on more scope in a sprint. If they do choose to take on more work, then the Dev Team decides "how much", and the PO decides "which PBI". Ideally, it should be a PBI that can be finished by the end of the Sprint, because we want to make sure we are delivering a PRI(potentially releasable increment.) However, there are other ways to achieve a PRI even with a PBI that carries over.

In general, if the "finish" is a day or two before sprint end, I tend to coach teams to spend the time either:
a) adding a small PBI
b) learning about test automation (as most Scrum teams have a deficiency in this area), or
c) investigating the upcoming PBI's -- but not starting work on them yet, or
d) working on some other sort of "improvement" activity, but never "refactoring".^1

If the finish is farther in advance than a day or two, then I coach that they should probably take on more work.

In all cases, I coach to inspect and adapt and be sure to discuss in the retro.

Some teams I've coached have decided to have a PBI or two already tasked out and ready to go "on deck" in case this happens. A couple of rules on that though -- 1. No one starts the on deck work without the normal discussion between Dev Team and PO -- and PO still has the right to select a different story to be brought in. 2. I coach the team and org what a sustainable pace means and that outside (outside the Dev Team) pressure to take on more than desired is a violation of Scrum.

^1 I don't really believe in "refactoring" except when it involves the current PBI you are implementing, as part of TDD, with already existing automated tests.

This is very interesting discussion! I agree with that underestimation should be discusses in the retrospective! But adding the new story is only allowed, when the story has the something to do with the Sprint goal and the Team is committed. Otherwise the Sprint cancellation.

The Scrum Guide is crystal clear : "If the work turns out to be different than the Dev Team expected, they collaborate with the PO to negociate the scope of Sprint Backlog within the Sprint".

For me, "different" means they overcommit or they undercommit. As soon as the Dev Team see they deviate from the goal, they should be transparent and negociate with the PO.

Posted By Olivier Ledru on 25 Nov 2013 07:35 AM
The Scrum Guide is crystal clear : "If the work turns out to be different than the Dev Team expected, they collaborate with the PO to negociate the scope of Sprint Backlog within the Sprint".

For me, "different" means they overcommit or they undercommit. As soon as the Dev Team see they deviate from the goal, they should be transparent and negociate with the PO.

Olivier, this has been a problematic point during my studies for PSM. I tough the Sprint Backlog may change in accordance with the PO, but only if the Dev Team may have overcommited the work to be done. Reading the other posts here, i understood that if the Dev Team has already finished all of his tasks for the Sprint, more work can be done, but it is a "bonus" and even if the Team fails to deliver this bonus, the Sprint Goal would be achieved. Am i correct?

> if the Dev Team has already finished all of his tasks for the Sprint, more
> work can be done, but it is a "bonus" and even if the Team fails to deliver
> this bonus, the Sprint Goal would be achieved. Am i correct?

Yes you are correct, assuming that any undone "bonus" work does not compromise the delivery of the increment.

Posted By Ian Mitchell on 26 Nov 2013 08:53 AM
> if the Dev Team has already finished all of his tasks for the Sprint, more
> work can be done, but it is a "bonus" and even if the Team fails to deliver
> this bonus, the Sprint Goal would be achieved. Am i correct?

Yes you are correct, assuming that any undone "bonus" work does not compromise the delivery of the increment.

Perfect Ian, thanks a lot!

We just started on the tasks for the next Sprint (got a head start). While in release planning we had many Sprints roughly planned out, we always had 2 or 3 Sprints planned in detail, though they could, of course, change until those later Sprints started (and sometimes did as we were agile about responding to the market, customers, etc., etc.).

I'd like to weigh in on this and pretty much agree with Charles and his comments:

  " In general, if the "finish" is a day or two before sprint end, I tend to coach teams to spend the time either: 

     a) adding a small PBI 

     b) learning about test automation (as most Scrum teams have a deficiency in this area), or 

     c) investigating the upcoming PBI's -- but not starting work on them yet, or 

     d) working on some other sort of "improvement" activity, but never "refactoring"."

I think also that the team makes a sprint commitment,  it's therefore a new commitment if they chose to bring in work and that commitment is to get stuff Done (done, done.)  It's not a great mindset to tell a team that they're getting bonus points, what they're doing is making a new commitment.  So it's good to be careful about that when you bring in new work - can you commit to getting it done?  If not, can you split the story to a smaller unit and get that done?  I know it sounds a bit hard, but self-organizing means self-disciplined. 

If the sprint boundaries begin to be degraded (oh i'll just start that new thing sooner) and blurry, then not only metrics get messy, but team mindset gets messy too.  There is always innovation, celebration, automation, dotting i's crossing t's, learning and tasking/preparation that can be served in the 36 hours leading to the end of the sprint. 

best,

k

I am not sure if this thread is still alive but I did have a question that expanded on this topic. If the team has decided to work with the PO to add a user story to their sprint is this work still considered 'committed' or if it ends up not being completed is it alright for the team to say, "It is okay, that was just adopted work."?

Should user stories on a Sprint Backlog ever be committed to at all, given that the backlog represents a plan and forecast of work for meeting the Sprint Goal? Wouldn't the Sprint Goal itself make a better commitment?

You make a good point Ian. This was a discussion we were having among the Scrum Masters here, I will bring those questions up. Thank you!

Have you used Zenhub? It has a lot of tools to generate different kinds of useful reports.

When we finish a Sprint early we add more issues to our current sprint and we increase our effort average and automatically for the next sprint we adjust the team average.

Maybe we could implement a reward mechanism for the team, for instance, I think it could be great if the members of the team can take a free day when they finish early with the main objective to keep them motivated.

Do you think it could be a good idea?

Thank you!

I would argue the differ Yamil. If you introduce such a reward, it will result in compromised story estimation. The team might tend to put more SPs on the items in order to achieve the prize.

The point is, it shouldn't be considered a good thing to have a flawed sprint planning.