5

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?

Improve this question
5
  • 2
    Can the new requirements be treated as additions to the old, or is it a radical change?
    – Robert Harvey
    Commented Feb 16, 2014 at 16:55
  • thescrumbucket.tumblr.com/post/7680619154/…
    – Robert Harvey
    Commented Feb 16, 2014 at 16:56
  • Most of the time these are not additions (in which case you should probably add a new story for next Sprint) but moderate changes.
    – Eugene
    Commented Feb 16, 2014 at 16:56
  • Can the changes be incorporated in a new story, or do you have to unravel the last story to make the changes?
    – Robert Harvey
    Commented Feb 16, 2014 at 16:57
  • They can be incorporated, but it usually means that we need to scrap some code and add some new code. Its still within the goal of the story, but it means we need more time. An example - do a wizard instead of the dialog with the tabs.
    – Eugene
    Commented Feb 16, 2014 at 16:59

3 Answers 3

Reset to default
8

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:

  1. 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.
  2. 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.
  3. 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.

Improve this answer
2

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.

Improve this answer
10
  • Actually, I would worry about this sort of thing. I'd be very surprised if it happens to every story - its a source of inconsistency. Velocity based estimation only works if your team are consistent in their estimates.
    – Dave Hillier
    Commented Feb 16, 2014 at 17:57
  • @DaveHillier: Velocity-based estimation works BECAUSE it's accepting of the idea that estimate can't ever be consistent. And Scrum isn't intended to make every sprint work like clockwork, it's designed specifically to identify issues early and deal with them. The OP has got as far as identifying the issue early, now they just have to deal with it.
    – pdr
    Commented Feb 16, 2014 at 18:37
  • This is incorrect. You're confusing consistency with accuracy. Velocity based estimation requires consistency. Otherwise you may as well use a random number generator for estimate. For example, see The Art of Agile (an excellent book)
    – Dave Hillier
    Commented Feb 16, 2014 at 22:14
  • @DaveHillier: If I accept that, by consistency, you meant something other than accuracy then I fail to see your original point. My answer was, in other words, that if there is consistency in surprise then there is no problem, and if there is an anomalous surprise then at least you identified it and can deal with it. I never suggested that estimates should be effectively randomised; only that there are always going to be surprises. Wasting time trying to spot those surprises in planning is futile, or at worst counter-productive.
    – pdr
    Commented Feb 16, 2014 at 22:47
  • My point is: your answer is at best ineffective. For velocity to work, an X point story must be roughly equivalent to any other story of the same size. If a UX person turns up mid sprint and suddenly the story grows >100% then you're screwed. That is too much variability for the estimates to work effectively. You may as well not bother to estimate. I have seen people use count of stories as a velocity tracker. It is less effective than using story points.
    – Dave Hillier
    Commented Feb 17, 2014 at 9:12
0

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.