{"id":4026,"date":"2014-06-03T09:00:44","date_gmt":"2014-06-03T12:00:44","guid":{"rendered":"http:\/\/blog.plataformatec.com.br\/?p=4026"},"modified":"2014-05-16T10:53:04","modified_gmt":"2014-05-16T13:53:04","slug":"how-to-deal-with-user-stories-that-are-not-finished-in-one-sprint","status":"publish","type":"post","link":"https:\/\/blog.plataformatec.com.br\/2014\/06\/how-to-deal-with-user-stories-that-are-not-finished-in-one-sprint\/","title":{"rendered":"How to deal with user stories that are not finished in one sprint"},"content":{"rendered":"

One of the most common questions discussed among the Agile Community is what should be done when a team doesn’t finish a user story (US) in a sprint? How can people track the progress made on an incomplete user story? In this blog post, I’ll share our approach to this question.<\/p>\n

According to the community, when a developer finishes their work in the last few hours of an iteration, they must try to help their teammates finish their work. Otherwise, it’s recommended they help prepare the next cycle of work, analyzing the next user stories, refactoring a piece of code that could be better implemented, or writing tests. It is not advisable for a developer to get a new user story started if they won’t be able to finish this in the same cycle. However, this first approach is not always possible because user stories can be underestimated or something can happen that would delay the delivery of the user story.<\/p>\n

A second alternative is to split the user story into two smaller ones and develop the one that can be finished on time. The first user story’s points are credited in the current cycle, the second one’s are credited in the next cycle. This approach improves the visibility of what was done in the current cycle. However, it hurts the agile philosophy, in some way it would be a delivery without business value for the customer.<\/p>\n

The third way is for the unfinished user story to go to the next cycle with the original estimate. When it gets completed, the user story’s full effort estimate gets credited to the velocity of the new iteration. This could skew the average velocity metric, so be careful, because this is important to the Product Owner (PO) for forecasting and planning. Also beware to not have a bunch of backlog items almost done: one user story delivered has more value than a lot of user stories 90% complete.<\/p>\n

How do we do it?<\/h3>\n

Usually, we use the first and third approaches in the following way:<\/p>\n