More often than not, most Agile teams have committed stories that are not finished by the time a Sprint ends. Teams struggle to understand the best way on how to address incomplete work. The easiest option most teams choose is to simply put those (unfinished) stories into the next Sprint. The problem with this option (attitude) is that more often than not it becomes a habit which can impact a team in many ways.
Once a team stops feeling the pressure to finish the work it committed, it gets into this antipattern, which results in increasingly more stories not finishing by the time a Sprint ends. I have seen that this habit, if sustained, can eventually impact the health of stories in the backlog. Why?
“Well, when we do not have to finish stories, how does it matter that stories are clearly defined or not?” - Is how the team members start to think. Such teams slowly become dysfunctional and often complain that Agile does not work.
I have also seen teams that actually work hard to finish most of their committed stories every Sprint. They, too, may move an item or two to the next Sprint without modifying the estimates on those work items. This could be an okay solution with the caveat, that the velocity numbers are now averaged over a given number of Sprints as opposed to the standard definition (of velocity) as the number of story points completed in a Sprint. Even such teams can get into the habit of finishing work items over two or more Sprints.
For example, an 8 point story that could not finish in one Sprint, but (for some reason) took three Sprints to complete, will now push the velocity definition to average over several Sprints.
Then there are teams that split unfinished stories at the end of the Sprint. They do it by splitting incomplete stories into two parts; the first part that got finished is burnt down and the second (unfinished) part is moved to the next Sprint. The original story estimate (in points) is divided into the finished and unfinished parts. For example, an unfinished Story “S” (with the size of 8 points) is divided into stories “A” (finished part = 3 points) and “B” (unfinished part = 5 points). There are a number of issues with such a split. First, teams do not realize that an 8 point story may not split into sizes that add up to exactly 8 points. Why? Because additional effort (testing, review, other repetitive work, etc.) needed for each of the newly created stories can increase the individual efforts (sizes). That itself is wrong. Another antipattern that comes in here is to understand that if you split an unfinished story, then you're actually not meeting your original definition of done (for the story) and you are not delivering to the Sprint commitment either. This is an important thing for the teams to remember. This behavior is also encouraged by certain tools that actually allow splitting of stories. Personally, I do not like this feature in digital tools, and this is one of the examples where effectiveness is lost at the cost of efficiency (for the tool).
The third option of addressing unfinished stories (at the end of a Sprint) is by moving an incomplete Story into the Product Backlog without modifying its estimates. This story may be considered for the next Sprint with the Product Owner's approval. The team, re-estimates this story for the effort remaining, and as a result, looses the credit for the partial work that was completed for this story in the last Sprint. For example, assume a partially completed Story “S” with 8 points being moved to the backlog before the Sprint ending and picked up again for the next Sprint. The team re-estimated the effort remaining to 3 points. By doing this, it lost the credit (5 points) of the partial work that was done. This option can demotivate or discourage the team and lower its enthusiasm, but it could also help positively encourage the team to only take the amount of work they can actually finish in a Sprint, or, split stories into smaller and valuable chunks that can be finished comfortably within the same Sprint. The team can also learn to work together and swarm together (cross-functional) to complete similar stories in the future.
How should a Servant 
Leader, Scrum Master address this issue? What would be the best possible manner to coach and help the team in such a way that they are not demotivated, and they don’t get into bad habits or antipatterns?
Taking a balanced approach, I would keep working with my teams, encouraging and guiding them to understand their capacity better, estimating together consistently and minimize unfinished work at the end of a Sprint. Whenever a team would become complacent and get into the antipattern of unfinished stories accumulating at the end of a Sprint, I would encourage the team members to take the middle ground - That is, supporting them in moving unfinished stories retaining the points, but working together to avoid this pattern becoming a habit. I would also challenge them to (be prepared to) lose partial credit thereafter (if this antipattern would continue past 3 to 4 Sprints). This provided a healthy path for my teams to dive deeper into understanding the mindset, skills and factors that would help them consistently deliver to their Sprint commitments. This helped my teams become better at understanding and negotiating the acceptance criteria, breaking smaller chunks of valuable work so that they can be consumed easily in a Sprint, estimating together as a team, becoming cross-functional with multiple people swarming together and finishing a bigger story, etc.
With such an approach, I found that teams would actually self organize around this healthy pressure and take accountability for finishing their work on time, which always needs a little stretch. This healthy challenge or pressure has always worked like magic.
I clearly remember making a statement (while coaching a high performing team that had gone a little lower in their performance over the years): 
My statement was misinterpreted by some team members and, with their eyebrows raised, they said: “Are you saying that we have to work over hours to finish all our committed stories?” While I was smiling, the Agile Champion sitting alongside and thinking deeply had an “aha” moment. He said, “I just realized what you meant, Amit” and then he shared the following story.
“I remember there was a time when we needed one of our Scrum teams to deliver 100% of committed work for the next 3 Sprints as we had a fixed date release coming up and could not afford to have unfinished stories. We arranged late evening dinners for team members, anticipating, some of them might be working late as they had committed to slightly more scope than their capacity for the current Sprint. I was pleasantly surprised to see that none of the team members actually had to stay late even for a single day and were still able to finish all their work with high quality. So, what was different? In retrospect, I realize that the team stretched out of their comfort zone - swarming, collaborating, staying alert and on top of all the tasks - which was the reason they did not have to spend evenings working at the office.”
As you can see, unless a team stretches to deliver on time for committed stories every Sprint, it can fall into the bad habit of consistently not finishing some of its work and will make excuses for not doing so.
Conclusion: There are a number of factors that can affect an Agile team, causing it to have unfinished work at the end of a Sprint. While this maybe acceptable for teams that show this behavior once in a while, it is actually an antipattern if seen consistently. Care should be taken to understand the deeper reasons that cause such behavior. Coaching, mentoring, inspiring Agile teams to understand the value of estimating as a team, planning and committing to their capacity and delivering to their commitments is paramount for helping them succeed with Agile.
Amitabh (Amit) Sinha is a servant leader entrepreneur, visionary, mentor, trainer and coach. Amit is highly passionate about Agile, its principles, values, and the human side. Amit is a people champion and strives to bring out the best in his teams. Amit leverages his expertise in Agile, Scrum, Kanban and people skills to increase team effectiveness and happiness. See more
