All the documentation I’ve read explains in great detail how at the end of a Scrum sprint, tasks are complete, user stories are implemented, and a customer gets a demo and accepts the implementation.
What I’m unclear about is what happens when this goes wrong.
I understand that sprints are timeboxed, so you can’t extend the sprint to make time to finish something. Especially when a team of newcomers to Scrum are estimating, they’re likely underestimate the size of tasks. How do we deal with a task (and therefore a user story) that is incomplete when the sprint ends?
How do we deal with tasks / user stories that are abandoned; the team discovers as they embark on the work that it does not have value?
How do we deal with tasks that are thought complete, but that the customer can’t accept?
I think I can imagine ad-hoc approaches to these situations when you’re working with index cards (shrug your shoulders, and plan the next sprint), but what do you do in Rally (or similar) where the software forces structure upon you?
If a User Story isn’t finished at the end of the sprint, then you move it to the next sprint.
If you discover, that a User Story has no value, DURING A SPRINT, then you should ask the product owner and/or scrum master, why it is even in the sprint. But if it happens, you close the story and the tasks and you may add other items to the current sprint.
If the customer doesn’t accept the product of the User Story, then you have to check why he doesn’t accept it. Either the acceptance criteria of the User Story is not fulfilled, in this case the User Story gets reopend and a Bug or an additional Task gets added to it. It may also be possible, that the acceptance criteria is fulfilled, but the customer has additional wishes, then a new user story has to be created and planned for the next sprints.