Claim some of the points? I generally don’t encourage teams to try and take partial credit for unfinished work. If it’s done in the current Sprint, then claim the points but if it’s not (if it doesn’t conform to the teams Definition of Done for whatever reason) then don’t claim any points until it is. The variation that this causes in velocity should even out over time as the team recognises the related tweaks required to their planning process and inspects and adapts accordingly.
Is the work still relevant? Don’t just assume that the story will “roll over” to the next Sprint. Discuss with the rest of the Scrum team in sprint planning and decide whether to take the story into the next Sprint or return it to the product backlog to work later. The priority of the work might have changed and having a conversation during the Sprint Planning meeting should force the product owner to reconsider the value of the work in light of the current situation.
Rewrite the item? If only a small piece of functionality is left to implement, then should the team rewrite (or split) the product backlog item? I would recommend that if the team is going to finish the item in the next Sprint then there is no need to rewrite the item (just add notes to the existing item to make sure everybody understands the remaining work), but if the item is going back onto the product backlog to be finished later, then it is often easier to manage the work by adding a new product backlog item that covers just the remaining work. If you are using a tool such as Jira or Version One then, as well as updating the notes for the item, remember to add appropriate relationships between the original and new backlog items.
As a side note; worrying too much about a consistent velocity is a dysfunction that will likely encourage other bad habits in the team. Instead of fretting over consistency, just take the average (mean) velocity and don’t worry about Sprints being consistent…what happens when people leave the team, are on holidays or off sick etc. Don’t worry so much about the process…let it flow! These are “estimates” after all. 😉
What’s the root cause? Why have you got unfinished work in the Sprint? If you can break the work down at the end of the Sprint (i.e. you have got work left unfinished) then why can’t you break the work down into smaller pieces beforehand…small enough to enable you to get it to done in the first place? Do you need to think again about possible ways to split your backlog items before starting them?
For example, can the work be split by:
- Acceptance Criteria
- Complexity (basic/advanced)
- Operation (Create, Read, Update, Delete)
- Price (basic, premium)
- User Type
- Data Entry Method
- Spike (R&D/Investigation)
Other things to consider if there is a pattern of unfinished work in the team:
- Discuss unfinished work in the retrospective.
- What can be done to break the habit? What is the root cause?
- Go light: Consider planning the next sprint conservatively. Under commit to over deliver?
- Sometimes it might be necessary to add a little light guilt if the team doesn’t finish everything.
- Whatever you choose, try and be consistent in your approach.
