1

Let's say we have a sprint of 2 weeks. In that sprint, the IT team has to implement some issues or features. How can we handle the case where the team finishes all issues/features ahead of time?

Do we pull tasks from the next sprint to the current one? Do we start a new sprint with some extra days in it in order to compensate for the days that were earned? Or we see the IT team playing games on the internet until the sprint ends and a new one starts?

I know that when there is not enough time in the sprint for the tasks to be implemented, some of them can go to the next sprint, but what about the opposite (when the tasks were implemented faster)?

Bogdan
  • 15,216
  • 27
  • 48
Efthymios Kalyviotis
  • 161
  • 3
  • 1
    This is VERY likely to be a dup of What if you finish all stories before sprint ends?. I'm not casting a vote to close to hear from the community. If you agree it's a dup, simply vote for closure on this one. If not, would be nice to understand the differences of focus between both. – Tiago Cardoso Feb 06 '21 at 10:55
  • You are right @TiagoCardoso. It is almost the same and the link you provided have a very nice interesting answer. I am not project manager and as such my question was not so much clear as the one you posted. Although the answers here helped me clarify some things, if you thing so I can delete the question. – Efthymios Kalyviotis Feb 06 '21 at 16:26

4 Answers4

1

A Sprint is never completed ahead of time. A Sprint is a timebox - it has a fixed start and a fixed end. In terms of events, the Sprint Planning is the first event and the Sprint Retrospective is the last. When it comes to finishing early, there are two possibilities. One possibility is that the team has met its Sprint Goal prior to the end of the timebox. The second is that the team has completed all of the work selected for the Sprint Backlog before the end of the timebox.

The team meeting the Sprint Goal before the end of the timebox isn't an uncommon occurrence. I'd even say that this is expected. I would encourage a team to craft the goal such that implementation of about 60-75%, with a maximum of about 85%, of the Product Backlog Items selected for the Sprint will lead to the completion of the goal. This helps the team to consistently meet their goal and regularly deliver valuable increments Sprint-over-Sprint, while still handling any unexpected events that arise in the Sprint. When the Sprint Goal is complete, the team can continue working on their Sprint Backlog for the remainder of the Sprint.

If the team has completed all of the identified work in the Sprint Backlog, there are a few options. They can continue on paying down technical debt or working on technical enablement. This would include refactoring, adding additional automated tests, improving the test and deployment tools and processes. The team can also spend additional time on refinement for potential upcoming work. There could be opportunities for cross-training to improve the team's cross-functional nature. Pulling in more work is an option, but it would be one of the last options, and I would want anything started to be completed by the end of the Sprint.

I would also point out that there is no "next Sprint" to pull work from. A Sprint is not planned until the Sprint Planning session. The reason for this is that the Sprint Review can change the order of the Product Backlog. As the stakeholders review the work that was done and synchronize with the team on changes to the environment, there could be new work added or existing work reordered.

Thomas Owens
  • 19,399
  • 2
  • 33
  • 62
  • Basically agree with you on "what can now be done," Thomas, but I suggest that this is a good place where project-management ought to have an input as to what to do next. (After taking the happy team out for beer-and-pizza on the company's nickel.) Everyone should also look over the estimation process – "why did we under-estimate?" Of course this is by no means an abstract question. – Mike Robinson Feb 05 '21 at 20:02
  • 1
    @MikeRobinson This question is tagged [tag:scrum]. In Scrum, along with many other frameworks built on the Lean and Agile frameworks, the team is self-organizing and self-managing. Anyone on the team can have an input, but the team decides how best to use its time. In different situations, the team may choose different options. Depending on which type of "doneness" it is, it may not be worth it to look at underestimation - for example, only if the team completed all items in the Sprint Backlog would I consider that as an option. – Thomas Owens Feb 05 '21 at 20:26
0

Hehe, that's why you should take more tasks than you can finish (Sprint Commitment - it is only in your head). But if you are already in this situation, I think the most sensible thing to do is to tackle Technical Debt or take some simple stories or bugs from the Backlog.

Otherwise you'll have to do the whole planning thing. And you'd have to change the dates of the meetings or decide if the next sprint will need to be shorter/longer than usual. And your PO may not be prepared to the unplanned planning. That's too disruptive

PS: Agile Manifesto doesn't have a notion of Sprints. Your question is only about Scrum.

Stanislav Bashkyrtsev
  • 1,046
  • 5
  • 10
  • I'm in the odd position of strongly agreeing with some of your answer and strongly disagreeing with other parts. I agree that cleaning up some tech debt, bugs, prepping for upcoming work and general tidying are great things to do with that time. However, the idea of taking more than you can do seems fundamentally broken and anti-scum. I say this because the goal of every sprint is to build a valuable increment of the product, not to do a set amount of work. Of course, it will take work to build that increment. Therefor, if you take on too much, you will never complete a releasable increment. – Daniel Feb 05 '21 at 16:02
  • @Daniel, suppose we have Sprint Goal=3 important tasks, and Sprint Backlog=Spring Goal + 10 less important tasks. What I'm trying to say is: Sprint Goal should be achievable, but Sprint Backlog must have more tasks than you can finish within 1 sprint. In other words: your increment will be equal to Sprint Goal + N of less important tasks, where N < 10. Spring Increment becomes simply "whatever we finished within the sprint". Otherwise we can end up in the situation similar to what OP describes - the team will have to improvise and decide what to do next in the middle of sprint. – Stanislav Bashkyrtsev Feb 05 '21 at 16:21
  • I can agree with that. In fact, the engineer in me completely agrees. The consultant in me is apprehensive that the wording can accidentally reenforce the common corporate preoccupation with busy-ness, but that's more about context than anything. Glad I could understand your meaning better. – Daniel Feb 05 '21 at 17:10
0

If you finish the sprint earlier, then the team gets together and decides what to do with the extra time. Obviously, the team will have to do something productive. Playing games on the Internet or staring at the walls while waiting for the sprint to finish isn't a solution.

You can do various things:

  • fix bugs that are in the backlog;
  • do some more features if you have something that fits in the remaining time and can be completed safely;
  • help the PO with refinement of the backlog;
  • add more unit tests or integration tests;
  • investigate technical solutions;
  • etc.

A sprint has a goal. The goal is not to finish all of the stories in the sprint in exactly the time allocated to the sprint. Sometimes you finish late, sometimes early, sometimes just in time. Just like in the daily standup, when the team plans what to do next to make sure the team reaches their Sprint goals, when you finish early the team plans what is the next thing they can do that adds some value to their project until they can start a new sprint.

Bogdan
  • 15,216
  • 27
  • 48
0

The sprint is not completed ahead of time but the sprint goal and its selected backlog items may be. If so, then the answer is to work on more backlog items. This is where it helps to have a prioritised (and regularly re-prioritised) product backlog, because it's easy to identify the next things to do if the backlog items already have priorities assigned to them.

Just to pick up on something else you said, I think it's wrong to view this as taking something from the "next sprint". Although you may tentatively know what you intend to do next sprint that isn't finally decided until the next sprint planning meeting. Leaving such decisions until the sprint planning meeting makes sense because it's only then you know the full picture: priorities might have changed or you may have completed more or less work than expected at that point.

nvogel
  • 6,295
  • 1
  • 9
  • 28