Un-Done work at Sprint end

Having un-Done work (items pulled into the Sprint but not Definition of Done at Sprint end) can be demoralising and prevent the team achieving a stable velocity. Many Scrummers ask, how do we account for this un-Done work, should it be re-estimated based on what is left to do or based on its new larger size?

If this happens only occasionally, go with the Development Team members' gut feel (e.g. spend five minutes per item estimating the impact in Story Points using poker) and move on. It will merely be a blip and the average velocity will balance things out. No biggie.

But if having un-Done work at the end of a Sprint occurs regularly, rather than merely treating the symptoms ("How to we account for carry-over of un-Done items?"), look to cure the disease ("How do we prevent un-Done work arising?") .

Symptoms to look for:

• No Sprint Goal. One the most effective patterns I can offer Scrum Teams it to start planning Sprints around Sprint Goals.
• The Sprint Goal contains connectives. For example: "Make services run on SQL Server and make the website open nicely in Chrome on Android and support features necessary for population genetics analysis." Clearly the two 'and' connectives strongly indicates there are three goals in this case.
• The presence of many items in the Sprint Backlog that do not relate directly to the Sprint Goal. What percentage of the items in the Sprint Backlog should directly relate to the Sprint Goal? While I think the value should be high, 100% may be idealistic and not practical.
• The team doesn't spend much/any time on 'Topic Two' during Sprint Planning. Take a look at the Sprint Guide section on 'Sprint Planning'. In my experience, the average Scrum team spends very little time on Topic Two.

Actions to cure the disease:

• Shorten the Sprint cadence. This suggestion might seem counterintuitive but I've personally had success with it. Shorter periods of time are easier to plan, which is why we do Sprints in the first place. It also reduces work in process (WIP) which helps teams focus on getting items to Done.
• Coach the team (or perhaps just the PO) on effective Sprint Goals.
• Teach the team to leave Planning with a plan. Yes, we favour responding to change over following a plan but we still value having a plan! Topic Two of the Scrum Guide outlines what such a plan should be.
• Coach the Development Team members on protecting the Sprint Goal by renegotiating the items on the Sprint Backlog mid-Sprint (reduce a PBI's scope, swap it for an alternative/smaller item, remove it from the Sprint Backlog, etc). Teach the team to refer to the Sprint Goal when they speak at the Daily Scrum. Make clear that a Sprint Goal without connectives is easier to protect.
• Ensure the Devs are making transparent which items are at risk of remaining un-Done and doing so early enough in the Sprint to allow renegotiation. A few of days before the Sprint end, the Scrum Master can take a confidence poll to identify items that are at risk of being un-Done. The team should discuss these items at Daily Scrum and adapt the Sprint plan accordingly.