So we estimate the story and put tasks on the board. Then during the Sprint the UX guy comes up with a user experience for the story that is more complicated than what we originally thought. So on one hand we want to implement the right feature for the user, on the other hand if we had known about the complexity of the UX during Sprint planning, we probably wouldn’t have committed to the story.
So what to do in cases such as this?
The same question applies to cases where a usability test or user feedback during the Sprint shows us that we should change the feature.
In general, where do you draw the line between clarification of requirements or adaptations and the changing of scope?
5
Well, the first thing that stands out is that UX effort should be part of your story point estimate.
But that point aside, when I’ve been faced with a story that wasn’t what it originally seemed I usually ask the following questions:
- Does the new version of the story invalidate the complexity estimate?
- If yes, pull the story from the sprint.
- If not, you may still be able to deliver the new version.
- Can it be broken down into smaller stories (at least one of which will be delivered in this sprint)?
- If yes, you can attempt to deliver the same number of story points without delivering the entire set of stories.
- If not, pull the story from the sprint.
- Does the new version of the story invalidate the sprint?
- By this I mean “has the sprint goal changed?” If so, cancel the sprint.
This is usually a decent compromise as the PO will still receive some of the promised business value and you’re not actually introducing scope creep in your sprint.
At the end of the day, UX is part of the story and, as MetaFight points out, your UX person should be involved in the estimation.
That said, don’t worry about it TOO much. If these kind of surprises are a regular occurrence, your velocity will automatically account for it.
If this is unusual, your business owner should be made aware and should be OK with dropping lower-priority stories (which may or may not include this one) from this sprint. If they’re not, you have a different problem.
10
I really like the answer from MetaFight, only one addition, if its usual that in every sprint there are histories with huge changes in complexity during the sprint (and perhaps forcing you to stop the sprint!), this is something important to discuss in the retrospective.
Its very important find the root causes, perhaps you need more collaboration of the UX people in the initial history definition?, perhaps you need smaller histories?, i don’t know, but probably your team has a better response than stackoverflow.