We are starting a Sprint today, first day of a 3-week Sprint. Our requirements from the client are still evolving, so remaining hours are estimated on some unclear values.
How should a deviation in overall design be managed in Scrum? For example, a requirement covered in this Sprint changes drastically, causing the Sprint to land up days behind schedule. Are we still committed to all the work, or do Sprint items get moved out to accommodate the change?
it sounds like you are unable to estimate prior to sprint planning or in sprint planning due to the large ambiguity of the requirement. You thus have one of two choices
1) Recognize the fact that the requirements are so ambiguous and that they are impossible to estimate. Thus the team will resolve these as they move along each sprint. i.e. stop estimating and get the team/product owner/business to always focus on building the next highest valued item. The team exists, there is work to do, the next highest value PBI is know and the team is trusted to do their best.
2) As a team push back in sprint review, telling the PO that the requirement is too ambiguous to work on and he/she should start doing his/her job properly. That is to keep the backlog in a healthy state where the requirements for the next sprint are clear, unambiguous for the team. As a team simply state the fact that you are unable to estimate it due to the ambiguity.
It is not the teams responsibility to make sure the requirements are clear, but that of the product owner. Second, its not the teams risk to take on work and be held accountable if the work is ambiguous. As the PO/Business how they are going to mitigate against the likely risk that the team is going to incorrectly estimate the requirement due to ambiguity, vagueness; and clearly state the team cannot be held accountable for this.
Scrum is an agile framework that embraces changing requirements, but the framework has rules for how and when changes can be introduced. Minor changes should be deferred, while drastic changes should trigger an Early Termination of the current Sprint.
One option is to defer changes until the next Sprint Planning session. Every Sprint starts a new cycle of prioritization and planning, so it's perfectly acceptable to complete a Sprint and then change the project's direction, scope, or priorities.
The idea with deferment is to provide change control by preventing changes in scope or deliverables from occurring within the current iteration. If the current Sprint Goal and user stories will still provide value, then the new work should be deferred until the Product Owner prioritizes it for a future Sprint.
Another option is early termination of the Sprint. If the current Sprint Goal no longer provides value to the Product Owner, or the changes are so drastic that they invalidate the current user stories, then the Product Owner may call for an Early Termination and an immediate return to Sprint Planning.
This has a cost to the project, both in terms of process overhead and lost work. That is why it is the Product Owner's decision: the Product Owner is responsible for determining what user stories have value to the project, and using the Product Backlog to allocate resources. If the benefit of failing early outweighs the cost of abandoning the current iteration, then it's generally in the project's best interest to avoid additional sunk costs.
