5

Sometimes we change user story scope to complete it during the iteration. For example,

Original story (8 points): As a user i want to save my data as PDF.

De-Scoped story: As a user i want to save my text data as PDF.

Now do i need to decrease the size of the de-scoped story as well?

EDIT

What do you do in such cases and why?

Improve this question
1
  • if you are wondering yes the remaining work will become part of another story.. but it will be estimated in the next iteration. Commented Aug 9, 2011 at 17:42

4 Answers 4

Reset to default
2

It depends.

When a story is de-scoped for whatever reason, we ask ourselves within the team, "Does the complexity of the story remain the same?" If the answer is YES, then no change in its estimate. If however, the complexity changes, the estimate varies accordingly. Estimate is directly proportional to complexity :)

Improve this answer
4
  • and this is done during de-scoping session...? or end of iteration? Commented Aug 9, 2011 at 17:57
  • Again it depends :P When we pick a story for an iteration and during the iteration we realize that the story has to be de-scoped for whatever reason, we first get the concurrence within the team on the complexity and then get client's concurrence on it. Typically, we have been doing it either at the iteration beginning and sometimes we do it in the middle of an iteration when we started playing the story. I don't see a point or situation as to why you would think of descoping a story after an iteration. Commented Aug 9, 2011 at 18:00
  • okie.. so when will you do it during the de-scoping session and when will you do it during the iteration end.. Commented Aug 9, 2011 at 18:02
  • I've updated my earlier comment! May you read it. Commented Aug 10, 2011 at 5:49
4

If you cut a story in half in order to fit it in the iteration, it's best to make another story for the remaining work, and then re-estimate both stories. (Even if you never schedule the new story, it's available.)

This is much easier to do if your estimates are sizes rather than hours.

Improve this answer
4
  • yes but when to do that re-estimation.. for the stuff that i will do in next iteration i will estimate it during the relevant iteration planning but what about the de-scoped stuff getting completed now.. when should team re-estimate the story.. Commented Aug 9, 2011 at 17:45
  • @Asim, You can estimate it now but it isn't scoped so that number means nothing. If it is descoped for a long period of time then the estimate may be out of date and would need to estimated again. Because of this I only estimate user stories that are in scope in the next iteration. Commented Aug 9, 2011 at 17:56
  • @mapel_shaft i don't think i get you.. descoping is done now i.r. during the ieration.. so i didn't get 'out of date' and 'long period of time' Commented Aug 9, 2011 at 18:00
  • re-estimate when you split the story. If you have to re-estimate again later, that's fine. Commented Aug 9, 2011 at 18:10
4

You don't have to, but it couldn't hurt to reestimate it whenever any changes happen. That way your story estimates more accurately reflect the work you need to do and allow you to either slot something else in if story scope got reduced or guide you to drop something if the story scope got enlarged.

If your story is now smaller in scope, you should also create a new story (or several) to capture the requirements that were dropped out of the acceptance criteria and estimate that new story accordingly.

The team I'm on does more or less the above. If we discover that the story as written turns out to be too large to be reasonably completed, we split out work that can stand on its own into a new story.

We don't always re-estimate the old story, though. It depends on how far we're into the work and what the remaining scope is. Sometimes it turns out that we are still doing the lion's share of the work and while the story might not be worth 8 points any more, it's still too big to be a 5-point story.

(We rarely have stories bigger than a 3 scheduled for an iteration, but I'm trying to use the numbers given in the question for some context.)

The new story always gets a new estimate. Stories that aren't done by the end of an iteration completed for whatever reason and cannot be split end up "rolled over" into another iteration and we re-estimate them at that point to account for the reduction in scope thanks to work already done (if any).

Improve this answer
1

You are trying to solve the problem which should not happen in the first place.

If the story is de-scoped it was incorrectly defined or estimated and should have not been planned at all (or the commitment was wrong). That is the first rule you should follow. If the story didn't contain acceptance criteria saying that you can save only "text as PDF" it simply covered everything and should have been sized that way and that size should have been considered during planning.

De-scoping story during sprint is wrong. You make commitment on the original story and you either deliver that original story or not. You can discuss this with product owner and either:

  • Implement part of the story and make it undone so it can be planned for the next sprint. The estimation of the remaining part to be implemented will be done before next planning.
  • Omit the whole story as not done and let product owner create another smaller one instead - sizing is not needed because still you are within sprint boundary and if you insist on this change you are still saying that you will do that new story in current sprint regardless of its size. The original story can be re-estimated before next planning and planned again.
  • If the story is the main target of the sprint, product owner can cancel the sprint and redefine / decompose the story for the new sprint. This should be very rare case.

In either case original story remains as is during current sprint and is marked as not done. Reasons for this can be different

  • Wrong story definition (including acceptance criteria)
  • Wrong understanding of the story = wrong communication
  • Incorrect story size estimation
  • Too optimistic commitment
Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.