Ideally we commit to work being completed and releasable by the time the sprint finishes. However sometimes things happen or estimating is a little bit out.
If we are approaching the end date of a sprint and a user story is not quite finished - maybe another day will see it completed - is it ok to change the end date e.g make the sprint 11 working days instead of 10?
Or should we strictly abide by the end date and move the unfinished story into the next sprint?
Or something else?
I'm going to have to agree with half of what Alexey R. said (do not extend), and disagree with the other half (you failed).
Sprints are time-boxed. Part of the reason for this is so that the Team can notice when they over/under commit, and therefore know to commit less/more in the future. By fudging the Sprint dates, you are destroying this ability to learn and improve estimation.
The purpose of a Sprint is not to complete all the Stories in the Sprint. It is to complete the Sprint Goal.
Is your Sprint Goal dependent on that one Story being completed? If so, you have failed the Sprint. This must be addressed in the Retrospective.
If not, then you have not failed the Sprint. Just take note of the fact that you did not complete all of the estimated work, and reduce your estimates accordingly. No big deal, move along.
Oh, and if you do not have a Sprint Goal? Then, in my view, you did not accomplish your Sprint Goal. Therefore, you failed the Sprint; you would have failed the Sprint even if you do complete all the Stories. Not having a Sprint Goal is a larger issue than one Story taking one more day to complete.
In the real world, people do change the end-date for Sprints. However, your question is really about whether you can extend a Sprint to complete unfinished work.
It's acceptable to plan a reduced-capacity Sprint to accommodate holidays or other business factors. It's not acceptable to treat Sprint boundaries as advisory.
The Sprint length should remain predictable. In the real world, it's occasionally necessary to make a Sprint shorter, move end-of-Sprint events up, or reduce the volume of work planned for the iteration. However, you should never extend a Sprint in order to accomplish more work.
A dynamic Sprint length is often a project smell. It's important that the time box for each Sprint is respected. Well-defined Sprint boundaries accomplish a number of things:
Remember that moving the Sprint Review doesn't just affect the Development Team. If affects the stakeholders too, and often impacts multiple events besides the Sprint Review such as:
While you can move the boundaries to accommodate significant events such as holidays, there's a cost to doing so. You need to make that cost visbile to the project, and to the organization.
Adjusting a Sprint's length can make sense if you're accommodating a major holiday, or if you have a significant capacity or scheduling problem. However, this has costs, which should be made extremely visible and paid as early as possible.
Reducing the capacity for the current Sprint meets that criteria, while extending the Sprint creates knock-on effects and pushes project debt into subsequent time boxes. Perhaps most importantly, extending a Sprint reduces visibility by hiding capacity, process, or estimation issues behind a utilization fallacy.
I've mentioned this before:
Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal.
When you extend a Sprint to do more work, you're preventing the team from facing up to (potentially systematic) errors in planning, estimation, goal-setting, backlog coherence, dependency management, story decomposition, and other related issues. This loss of visibility and transparency creates project debt that becomes evermore burdensome every time you do it.
First, determine whether or not your Sprint Goal is at risk. Rather than extending your Sprint, talk with the Product Owner to determine whether the Sprint Goal can still be met if the work item remains undone or is re-scoped to fit within the current time box.
If the Sprint Goal can't be met, then the Product Owner should call for an early termination. The team should then hold a retrospective, immediately followed by a return to Sprint Planning.
Remember that a Sprint can succeed without 100% of planned work being done, and it can also fail even if every planned backlog item is completed. It's the Sprint Goal that matters, and if the Sprint Goal can't be met within the time box then the cost should be paid immediately and very visibly, rather than hidden by "framework adjustments."
I wouldn't change the date since the process should be established including established sprint duration. Having such things constant will help you to improve you process.
You didn't manage to accomplish all the tasks within a single sprint. So you failed the sprint. This is the subject to investigate within the retrospective to find what was the reason. Probably you have issues with your estimation process or with technical debt or you produce to buggy code or you have problems with having your tasks well-defined.
In other words moving sprint end dates won't let you define and address the procedural issues. It also makes your stackeholders less trust you.
The Sprint end date should not be extended. By extending the end date, the Team may be completing what was planned in the Sprint. But they will lose the discipline and dedication of completing what was committed within the Sprint. It will also impact the Team's velocity, as the size of Sprints will vary.
Positives: - You get the work done a day or two earlier - Burn down looks good
Negatives: - Your velocity means nothing, due to the timescales being variable - Your team have not met there commitment and you will never know why - Its ok to do the same thing next time, so planning means nothing, may as well go Kanban - You will have to move all ceremonies to adapt to the change - Product are no longer able to estimate based on velocity and larger roadmap is no longer valid as sprints are not a fixed time period.
I would avoid changing the sprint end date at all costs, there may be small exceptions to this, example "if we deliver this a day late then the company shuts down and we lose our jobs" and it really will have to be as dramatic as this for me to extend a sprint.
