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

Question

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?

Answer 1

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.

Answer 2

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.