What to do with the story if new information emerge during the sprint.
Imagine there is a story which has been refined and estimated for 3 points during the sprint planning meeting.
Now it’s very common that during the sprint new information can/will occur. Chances are that this new information will increase the complexity of the story or maybe even change the whole story.
What’s the next best step?
Option 1: Continuing building the product which has been agreed with the Product Owner during the sprint planning meeting?
Option 2: Inform the Product Owner, modify the complexity and work on it, perhaps even remove some lower priority stories.
Option 3: Remove it from the sprint due to too many uncertainties?
Option 4…
As with everything else, it depends...
How will removing or changing the story affect the sprint goal? Can the team meet the sprint goal without this story?
I would clearly rule out option 1. Even if that's what the PO initially asked for it is not what she wants anymore.
Given that the sprint goal is not compromised:
If the work is significantly larger than initially estimated I would put it back on the backlog and refine it further, so that it can be included in a coming sprint. If it is roughly the same size and is of high importance I would consider removing other stories.
But, most important of all. Discuss this at the next retrospective. Why did this happen and how can it be avoided in the future? Review and update your definition of ready, if you have one.
It's important for the whole Scrum Team to look at the sprint forecast in the round, and to expect a Sprint Backlog to change to some degree. Certain items may increase in scope, others may decrease, and some will simply be clarified.
Changes in technical tasks on the Sprint Backlog do not need to be discussed with the Product Owner. However, changes to the rubric of the PBI's or their acceptance criteria will need to be agreed with the PO. After all, those PBI's have been drawn from the Product Backlog which he or she owns and they have not yet been completed. Moreover, any such changes could conceivably affect the Sprint Goal and the PO is obviously a stakeholder in this.
Firstly we need to acknowledge that it's equally likely that complexity can decrease on a story/PBI - that's part of the nature of uncertainty. I believe people naturally embrace a reduction in complexity, but fear an increase in complexity - yet these events are fundamental reasons why many people accept that Scrum is the best way to develop their products.
In any case, my perspective is this:
When the nature of a story changes, it must be referenced back to the sprint goal, and it will likely need to be discussed with the PO to ensure that in light of the change, it still represents value in the scope of the current sprint.
If the complexity of the story changes, then it will require re-estimation to a greater or lesser degree. Certainly if the implementation has changed (a la emergent design) then there may be a knock on effect on the other stories in the sprint backlog and the effective order of implementation. These will in turn have a knock on effect on the velocity of the team in the current sprint.
The story may well be best returned to the product backlog, re-estimated and re-prioritised. A further decomposition may be possible/desirable given the changes and this will re-enter a sprint backlog when appropriate.
Key to re-iterate Fredrick's point. This is a prime candidate for discussion at the sprint retrospective - it will give the opportunity to inspect not only why the scope changed, but also how the team coped with the change and how they can adapt both refining and how they deal with uncertainty in future sprints.