Scrum – How to Handle User Story Changes at End of Sprint

Given they've just been given the story during planning (regardless of it being a new story or not having estimated it earlier) you have a few choices.

First, you can ask the product owner if the story can be left on the backlog so that it can be properly checked and estimated during this sprint, and take it next sprint.

If that's not possible, another option is to do it in a spike - a time-boxed story to investigate something or to try something out - and then you'll have a head start for doing it next sprint.

Finally, if you really must start on it this sprint, then try and find out as much as you can during planning, and take the story but make it clear of the risk that it may not be completed this sprint. If it doesn't get completed, so be it, you've done some of it and now know a lot more about it for the next sprint.

Remember, estimates are just the best estimates with the information you have at the time, and can be revised later when you have more info.

Also remember you should be spending about 5%-10% of the sprint in refining the backlog. Doing this really helps keep the planning meetings shorter, more focused and more productive.

In my current team we do c).

The velocity should account for things the team really finished in the sprint. Something that was not delivered has no value for the customer, so we don't count any points for it, it's all or nothing.

So we shift the whole unfinished story on to the next sprint and all its story points will be added to the next sprint's velocity. Velocities even out over time and we take an average of the few previous sprints as a reference to determine estimate future velocities.