Do “almost finished” tasks or stories justify planning with overload in the next sprint?

Question

The case in question:

The sprint is almost over and one of my Scrum teams did not finish some tasks. (The reason for this is not essential for this question and will be addressed accordingly.) One of them is a classic "90% done" case with a rather large number of story points and will be part of the next sprint - like in the question here.

We did backlog grooming and some preliminary estimation for the next sprint and discussed how to handle this unfinished task. While we all agree that it won't count towards this sprint's velocity, I argued that the we should not re-estimate the almost complete case with 1 instead of five story points, because I want the true complexity and the total work done to be still visible. And looking back the estimation was correct. - We are just transitioning to (scaled) agile and some management levels need to "see" that we are still productive in more ways than delivered products.

Obviously the velocity in this sprint will go down, but the transferred "already done" parts should rise it again next sprint.

So far we all agree.

But as our teams are rather small, four points is a big lump. I suggested that for this task only and with proper documentation we could consciously plan an overload of four points.

Is that a feasible approach or will I

• run into problems I don't anticipate yet
• set a bad example with a team that has been transferred to agile just a few months ago?

Answer 1

When a story isn't done at the end of the sprint, then the points of the story don't count towards the velocity of that sprint and the story goes back onto the backlog.

If during the planning of the next sprint the story is selected to be finished, then you can do a quick re-estimation of the remaining work. This estimate should only be used during the planning session to ensure that you are not under-loading the sprint with stories with a large number of points where actually very little works needs to be done to complete them.
On the board (and in the velocity of the new sprint), the original estimate of the story that was carried over should be used.

Such carried over stories is one reason why the velocity can vary from sprint to sprint and you should use an average to calculate the capacity of the team when planning a sprint.

If the non-completed story does not get picked up in the next sprint, then it might be better to plan it for the full points value when it does get picked up again, because it will also take time to get up-to-speed again with what the state was when the team stopped working on it.

Answer 2

Do not try to make your velocity look better than it is. The way forward is to acknowledge that the task was not completed you overestimated what you could do in the sprint and failed. But that is life, and an opportunity to learn.

So 0 points for the incomplete task.

As for the new sprint, estimate the work needed to complete the task in story points and count it as a normal task.

You are worried that your velocity will look too low, you should be worried that your velocity is artificially too high.

Having a velocity that is higher than you can actually achieve will set you up for failure again and again.

Answer 3

In our team we use a few different ways to handle carry-over stories, depending on the circumstances.

• When the sprint is almost over and everything planned is already finished (which happens every other sprint) then we start on the next stories on the backlog (but don't commit them to the sprint release). These are auto-included in the next sprint, and for reporting purposes all story points go to the next sprint.

• When parts of the story are completely finished and have business value on their own, then in general we readjust both scope and estimate for the original story, and the remaining parts go back to the backlog.

• If the original estimate for the story was off (which sometimes happens for large, complex stories) we try to learn from it :). No story points in the current sprint, re-estimate the whole story in the next sprint planning.

When some of the stories carry over from the previous sprint, then in the sprint planning you don't start with an empty sprint backlog. The team decides how much extra work they can take on top of that. For example: normal team capacity 100 SP/sprint, 20 points already in progress, team decides to take 90 new SPs, so then you have 110 SPs in the sprint at the beginning of the sprint.

The major downside of this approach is that the velocity reports are not as nice as some of the managers would like them to be. But in the long run it all evens out, and this way everything that is potentially releasable gets delivered as early as possible, and the team gets credits for their work.

---

A little bit of background: originally this team had a very strict approach to sprint deadlines, so they would refuse to take on more large stories than they could finish within the first week (of the 2-wk sprint), and use small and safe work for the remaining part of the sprint. While this resulted in a nice empty sprint backlog at the end of the sprint, this had too much influence on the question 'what shall we work on next?'.

Answer 4

This is not a question for an easy answer. There are going to be many opinions on what to do, but I suggest you start with identifying the various needs you have to meet, and come up with a solution based on those. Example:

1. A team "needs" to understand how they are working, and identify any opportunities for improvements. Sometimes, changing story points masks issues that should be addressed.
2. The Product Owner "needs" to be able to know how many story points were estimated for a Feature (often these are aggregated at the feature level) or Release (AKA "PI" in SAFe-speak) and may ask for a burn up at the feature-level (or PI) to demonstrate progress toward delivering an MVP or MMF. Changing story points can skew the numbers and cause some confusion.

There are some "guard rails" to help guide the decision.

• Work is either DONE, or not. Incomplete work does not count toward the sprint in which it was completed.
• Incomplete stories should be re-prioritized (it is not a "given" that they are carried over to the next sprint, they may return to the backlog or be abandoned).

That being said, I have seen many teams handle this in various ways.

1. If the incomplete story is still valid and approved by the PO, the entire story carries to the next sprint. What these teams do often is TAG these stories as carry over and estimate how many points of "remaining work" they represent. So if it is a 13 points story, but only has 1 point remaining, they do the math to adjust for that by subtracting 12. This leaves the original estimate for historical purposes as you suggested, while helping the team figure out their capacity. In this case, YES, you may have "more points" than your velocity-based capacity "threshold". But velocity can change slightly, it is not written in stone.
2. I have seen teams split the story (Rally, for example, has very nice functionality for this), and apply some points for the part of the story that "stays" in the old sprint and then apply points to the part that carries forward. This approach is convenient, but it does violate the principle that "Done means DONE", and hides the fact that estimates may be poor and work is carrying over, so the opportunity to learn and improve can be lost. (This is not my recommendation for those reasons)
   3. The worst solution I saw was that they just marked the old story DONE, maybe they reduced the points, maybe not, and then they opened a new story for the remaining work (often testing!). This is an ugly solution by any standard, IMHO.

What I would focus on is this: "One of them is a classic "90% done" case with a rather large number of story points"--the key here is LARGE story! Remember INVEST: stories should be SMALL. The team should look at either splitting stories (preferred) or swarming them. But bigger always means more risk, even when swarmed.