During sprint we found foresight was not good so.....
I am acting as Scrummaster and couch to a team new to SCRUM. We are in the 5th sprint and a feature that we thought was going to be separate was discovered to be better as an added functionality to a previous feature. During sprint planning it was not recognized that this change meant the previous feature should have been architected differently. So the team is not going to get the feature for this sprint done by sprint review unless we don't refactor and, as the developers say, simply shoe horn it in. The developers brought this issue up about 1/2 way through the sprint.
So...I'd like to hear how others would handle this. I hope the description is clear enough.
Thanks
Does the Product Owner value this feature, and if so is it essential to the present Sprint Goal?
yes, it's a major feature.
The Development Team seem to be saying that, if work is "shoe-horned in" around the current architecture, then the Sprint Goal can still be met. That should therefore be their position as the Sprint Goal ought to be preserved.
They do however have a duty to explain the situation to the Product Owner. If the product would be severely compromised by this shoe-horning of work, such that technical debt is unlikely to be repaid and the value ever recovered, then the attainment of the Sprint Goal might no longer make sense. The Product Owner would then have the option to cancel the Sprint so the team can rework the architecture to a firmer foundation. Ken Schwaber has called this option "scrumbling".
Cancelling a sprint is extreme and ought to be very rare. Usually value can be recovered by amortizing the repayment of technical debt over subsequent sprints. It is best to meet the Sprint Goal wherever possible, even by shoe-horning, and to adapt the product and its architecture over the course of future development. The key is to keep the rework transparent on the Product Backlog.