What we should do, if after planning we still have some free time in Sprint (i.e. unused forecasted capacity) and no tasks that will fit in it

Question

A question about Sprint planning. Let's assume, that Team velocity are 20 Story Point (SP). The most prior Stories in Product Backlog are A (12 SP), B (5 SP) and C (4 SP).

It's easy to see, that if we will take all three tasks (21 SP), most likely we will not finish task C. But if we take only A and B (17 SP) we will finish sprint early.

There are two possible solution:

• take all three task in current Sprint and hope that we will finish it all
• or plan to take only A and B tasks, and after we will finish them, take task C during Sprint.

It seems, that these two solutions are similar. But, in my opinion, there is a difference. It is motivation.

First solution: it will motivate Team to hurry up. But demotivate, if team will not doing all planned work. By my experience, second case happen more often.

Second solution: I saw, that work usually takes all planned time. And it's not related, how exactly time we allocate to this work. So, if we will plan only two tasks in Sprint, we likely will do this two tasks whole Sprint.

What Scrum say about this? Which way we should use?

Answer 1

Focus on accomplishing the Sprint goal

Scrum is not just about completing stories. It is about delivering business value. So, you should start by discussing and agreeing on the Sprint goal. And then, the development team can have further discussion and negotiation with the Product Owner. For example, the development team can propose dropping some bells and whistles from one story or modifying another story - all in the interest of reaching that Sprint goal. But the Product Owner makes the final call.

After that, the velocity, story points and prioritization is a good starting point for sizing. But, remember that velocity cannot be a precise number. It can only be a range - some thing like 20 to 25. However, your question is still valid. Do we squeeze more than what the team can deliver or plan it safely?

What Scrum say about this?

Scrum wants the team to create a potentially shippable increment of the product ready at the end of the Sprint. So, at the end of the Sprint after seeing the Sprint Review, the Product Owner should have the option of saying, "All right ship it (or deploy it)!" So, the development team should keep that in mind and commit accordingly.

You can also try what @CarynRose suggested and try to split the stories into smaller pieces.

One option I have explored: If the team has made good progress in the first two stories, I add the third story mid-sprint. However, I always ask, "Are you sure you can add it now and completely finish it and be ready to ship?" If there is any hesitation, I won't add it.

Another option: At the time of Sprint Planning, if there is bandwidth, you can schedule a time boxed research story to reduce risk in a backlog item (in consultation with the Product Owner, of course).

Answer 2

Ideally break down the larger story. But there are productive ways to use left-over time in a sprint. How about:

• Spend time adding more automated regression test coverage
• Spend time tackling technical debt
• Do spikes on complicated stories planned for the next sprint
• Get the team together to discuss coding standards, design and architecture

Answer 3

I think that A task with 12 story points could probably be broken up into 2 smaller tasks, so that you have A, B, C and D, which might lend itself to a different prioritization.

Answer 4

This is the most common problem faced in project planning. And the solution lies in the nature of the problem. In your case if other team depends on either of A B or C that would be high priority and a MUST to complete in this sprint. Similarly if there are no dependency to any of the storypoint and you can ship a working product without it. It's ideal to push that story point to next sprint and cover as part of the product backlog items.