How to face this particular situation?
Hi guys,
I would like to share with you a situation to hear opinions on how to resolve it.
We are in a sprint with a sprint backlog of X points. At half sprint more than the half of the functionality has been developed, however, in the daily scrum an alarm is triggered. The beginning of the implementation of a story (estimated at X / 2 points) revealed the fragility, rigidity, viscosity and immobility of the code. Team members decided that the best way to deal with this problem is reimplemented part of the core of the application, this means that the functionality can not be completed within the sprint and that the estimate assumes 3 times higher than expected. Given this situation and considering that each sprint normally ends with a new release, what attitude should have the PO?
A) Focus on the features that can be finished, release the version and abort the sprint to re-estimate the functionality that could not be done.
B) Let continue the sprint, starting to develop the reimplementation in a branch (or as the team deems appropriate) and in the new planning meeting rename and re-estimate the functionality
In any case, another question, how to explain to stakeholders a significant error and the no visual changes (redesign)?
Regards
Hi Javier
From what you describe, it seems that the Sprint Goal cannot be achieved. Option A would therefore seem to be best. However, the Sprint can only be aborted with the approval of the Product Owner. It's the Product Owner's responsibility to explain the error to stakeholders. The team should offer a way forward to stop a repeat of the situation, such as by adopting more aggressive refactoring practices to stop the future build-up of technical debt.
Thanks Ian for your reply,
Some lines of reflection in search of someone to corroborate me or make me see the light.
I know that a sprint should be aborted if the team is unable to meet the goal of the sprint or external circumstances negate the goal value.
I know that a sprint should have a single goal, but sometimes it is hard to aim a single target. In this case, half of the functionalities have a goal and the functionality which requires a major redesign has another.
I've been thinking and I'll redirect the question. How should the PO address a sprint when one of the features finds major design shortcomings that involves a large refactoring and its estimate is much higher?
A) It is mandatory abort the sprint.
B) It is optional.
In this case, I think there is no rule written and best practice is common sense.
A problem I see aborting the sprint is the sync break with other development teams. In the case that there is dependence between groups, the rhythm can be broken because when a group is developing, the other group is not available, they will have to make a retrospective and a new planning meeting.
What do you think?
Regards.
Hi Javier
It is optional to cancel the sprint (therefore B). Cancellations are rare because of the trauma they cause, and the need for replanning. It's at the PO's discretion whether or not that happens. If it is aborted, then the PO should work with the team to ensure that as much value as possible is released, and a new Sprint can then be started.
There is no need for a sync break with other teams. If a Sprint is cancelled, the Sprint that replaces it only needs to occupy the remainder of the timebox, i.e. the time that remains.
Hi Javier,
I think the spirit of a sprint cancellation is to highlight the cost of changes of priority of customer needs. In your case priorities have not changed. Instead, you have discovered an error in estimation. Also, cancelling a sprint is like accepting all the work that we've done till now in this sprint is wasted, we should have been working on something different altogether. This is not true in your case either.
Thus, I would try and split the story in question and see how much can be done in this sprint. Even if it is 10% of the original story, we still have 55% of the sprint goal achieved (the other X/2 story points plus 10% of the "bad" story). Or, just drop this "bad" story and pick up other stories that will fit into this sprint.
Then, I would add a new product backlog item to refactor the code and move it very high up on the list. This new item would at least be higher in priority than the bad story itself. The Product Owner will, of course, agree to this prioritization and will get addressed (at least in part) in the next sprint.
I would go with option A except aborting the sprint. PO should accept whatever is completed by team following the DoD and rest should be marked as Not Done.
Based upon the priority of Not Done items decided by PO, team should re-groom them and take them up in future sprints.
Cheers
Sanjay
I go with Vasan on the cancelation of a sprint, the scrum guide is very clear on this: "A Sprint would be cancelled if the Sprint Goal becomes obsolete" (Page 8) so it is neither mandatory nor optional.
Thank you all for your answers,
I finally understood that sprint should not be aborted and it continued its normal course. All stories except the problematic one were accepted and even the team has found a solution that requires much less effort than expected.
Anyway I remain concerned about the quality of the code, so I think as Vasan suggested it would be good to include in the product backlog a refactoring story. In this case I am worried about how to define it, because it should be easily testable, should focus on the problem and the team must be able to estimate it. I thought about using some quality metrics but I think it is not easy to estimate such a story.
Regards.