12

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?
Improve this question
2
  • 7
    The first 90% of the task takes 90% of the time. The remaining 10% of the task takes the other 90% of the time.
    – Bradley Thomas
    Commented Feb 24, 2017 at 15:18
  • 5
    "some management levels need to "see" that we are still productive in more ways than delivered products." - ouch. That's really unfortunate.
    – Bryan Oakley
    Commented Mar 22, 2017 at 23:39

4 Answers 4

Reset to default
6

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.

Improve this answer
3
  • 2
    Sorry, but that's wrong. When a PBI is not done by the end of the sprint, it gets re-estimated for the remaining amount of work and that new estimation is what goes into your velocity for the next sprint, not the original estimate. If you had an 8, but only finished 75% of it, so now it's basically a 2, that 2 is the effort you're expending in the sprint to finish it up, not the 8. By using the original value, you're padding your velocity by an extra 6 story points here. The point of velocity is to see what your team can handle, so it should reflect only the work done in the sprint.
    – Chris Pratt
    Commented Jul 28, 2017 at 15:31
  • 2
    @ChrisPratt: The velocity measurement should be an average over multiple sprints precisely to average out the effects of unfinished work being carried over to another sprint. Assuming that you don't propose to count the 6 points in the sprint that didn't complete the story, you would be losing 6 points of effort in other statistics that are based on the estimations. Also, if you look back at the story later for reference in other estimates, you would be mis-representing the complexity of it.
    – Bart van Ingen Schenau
    Commented Jul 29, 2017 at 10:03
  • 2
    Velocity is a measure of how many story points got done. There's no partial credit. If you have an 8-point story and you only finish 3/4 of it, you didn't complete it. Those 8-points go away. The story is then resized for the remaining work, and goes back in your backlog, where you may or may not work on it next sprint. This deflates your velocity, but that's the point. You weren't able to complete the work, so your velocity should go down.
    – Chris Pratt
    Commented Jul 31, 2017 at 13:56
8

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.

Improve this answer
5
  • Doesn't this understate the work already done, though?
    – Bradley Thomas
    Commented Feb 24, 2017 at 15:17
  • The point is that this most likely is not an outlier, it rarely is. But if it is an outlier and the rest of the sprints do have a higher velocity then chalk this sprint up to things that happens. But to know it is an outlier you will have to know the truth about it. A task is not done unless it meets the definition of done and it doesn't.
    – Bent
    Commented Feb 24, 2017 at 15:29
  • I was not wondering about "not finished" part, just about how to plan with the already done part. And for the sake of the argument, let's assume the reasons for non-completion are perfectly valid, nothing the team was in any shape or form responsible for and the planning correct.
    – Stephie
    Commented Feb 24, 2017 at 15:38
  • 4
    @Stephie There aren't "valid" and "invalid" reasons for a story to be incomplete. What's more relevant is whether the reasons are recurring and/or actionable. If the reason isn't recurring then the dip in your velocity should be brief. If it is recurring, then you really do just have a lower velocity. Either way, "compensating" is unnecessary.
    – Derek Elkins left SE
    Commented Feb 25, 2017 at 2:58
  • 1
    Yes, this understates the work done, but that's what you want. People seem to want to gamify velocity, as if it's supposed to be pushed higher and higher. That's not the point at all. Velocity is a measure of how much work your team can do at a normal pace during any given sprint. If you overdid it, and didn't finish all your story points in your sprint, then that likely means your velocity is tracking too high. It's not about looking good or bragging rights; it's about being able to accurately measure how much the team can do.
    – Chris Pratt
    Commented Jul 28, 2017 at 15:40
1

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

Improve this answer
1

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

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.