What happens with project backlog if sprint due date is missed?

Suppose that I have project backlog item with effort of 40 hours. My sprint is 40 hours (1 week) and I have one developer in team.

So developer creates child task to pending backlog and estimates work to 40 hours. At the end of the sprint developer didn't succeed in resolving his task. Suppose that developer works only and only 40 hours per week.

On the next week there would be new backlog items and new sprint. What should I do with backlog item and velocity graph?

Obviously backlog item is not resolved on that sprint. Should I estimate the remaining work and subtract it from effort , so that now I see that our velocity is, say, 38hr per 40hr sprint?

I prefer to not recognize any of the effort in my velocity unless we've achieved "Done". My preference is to show velocity of value delivered, and a partially working but incomplete solution that doesn't achieve the goal of the story doesn't deliver the value that was estimated.

So the 'value' is the same, rolls over to the next iteration, but the estimate for task hours remaining may need to be adjusted. In fact, I usually only suggest to my team to track task hours remaining for the burndown.

The next sprint, when the work reaches "Done", we recognize the full value award, and the task hours remaining should get to zero.

• What if I would close that backlog in the next sprint,say #2? I mean sprint #1 would be 0 velocity in graph, then in sprint #2 developer finally resolved his task and I close backlog with other backlogs that were scheduled in sprint#2(suppose 38hr). That would be 78hr(40 from sprint#1 + 38 from sprint#2). Avg velocity would be 78/2 = 39hr. Is that ok? – nikita Oct 29 '13 at 13:53
• @nikita: No. At the end of sprint #1, you estimate how much work is remaining for the unfinished work (say that the story needed only 8h to complete at the end of sprint #1). If in sprint #2 the story gets closed with additional stories done (total 38h), then sprint #1 has a velocity of 0 and sprint #2 a velocity of 38h. The 40h worked in sprint #1 on stuff that didn't get finished then is just lost. See it as a penalty for not completing the work by the deadline if you wish. – Bart van Ingen Schenau Oct 29 '13 at 14:06
• @BartvanIngenSchenau suppose, sprint#2 has 38hr of backlog items that belong to sprint#2 and i need to finish backlog from sprint#1(2 hr of work). So penalty here would be that I can't count unfinished sprint#1 backlogs, but I must find time for them in sprint#2 so I would have to plan less in sprint#2. Obviously my velocity will reduce - that is ok. Do I understand your idea correctly? – nikita Oct 29 '13 at 14:14
• @nikita: Almost. Unfinished work of sprint #1 gets put back on the product backlog (with a new estimate) and gets planned in the same way as work that hadn't started yet. The PO even has the option to defer finishing that work until a later sprint (or never). So, when planning sprint #2, you take on as many top-priority items as your team can handle. Work left over from previous sprints only gets finished if it has a high enough priority on the backlog. – Bart van Ingen Schenau Oct 29 '13 at 14:26
• This is also why most estimates at the story level are usually not in hours. The 'value' you are recognizing is not the same as the hours spent delivering it. If you are running a scrum-like reporting of velocity, you would normally be reporting on points of value delivered, and then also tracking hours remaining on tasks. You may want to track hours spent as well to know about your efficiency on tasks, but I would normally consider that an extra tax on the developers that doesn't really give you much value for the effort put in. – Jay S Oct 29 '13 at 18:02

I would say your story is too big and would require cutting down into smaller tasks. Generally in agile teams I have worked with we tend to do as much as we can in the sprint, anything not finished just goes on the backlog to be re-prioritized for the next sprint, as you may not want to play them in the next sprint.

If you have the case of a story where it is partially done in a sprint, but not entirely you need to make the call if the tasks (assuming you have some task level items under a story) are complete and if so can they be safely left in the live code base. If so the next time that story is played the developer working on it will see that 5 of the 7 tasks are complete and pick up where the other developer left off. If it is not stable enough to be put in, you can either scrap it and let someone else start fresh, or park it in another branch for the developer to resume in another sprint when it is needed. Although working this way would require developers to manage their stories as branches in the source control system.