We just adopted Scrum and completed our first sprint (yeah!)

At the Sprint Review, we demoed a User Story for feature X. This feature X worked exactly how described in the User Story from initial business analysis and details we worked out during product backlog grooming and sprint planning. However, after the user saw feature X in action they wanted some tweaks (not shocking, purpose of the demo and feedback loop).

My question is:

(a) Do we consider the original user story done and create a new user story to handle the new requirements in a future sprint?

(b) Do we consider the original user story unfinished, roll into backlog with more detailed requirements that will turn into more tasks in the next sprint?

If (b), in sprint planning do we re-estimate the story point weight of the story now knowing that 90% of the work is complete? So if it was originally 5 pts it might now be 2 pts?

5 Answers 5


Coming up with new ideas after being presented new finished work is part of a normal iterative development. Most important is if the story brings what you 'knew' when you started the sprint. New insights are for new stories.

Keeping stories open or rejecting stories is for when you got things wrong or missed things you had discussed.

So definitely option A.

  • Thanks! I agree with everyone's answers so far, but yours is the most succinct and easiest for me to digest and present back to my team =)
    – Doug Ayers
    Mar 10, 2013 at 0:20

It boils down to your "Definition of Done". Is your story Done according to that list?

My opinion though is to consider the original story done and you should create a brand new one for the next sprint.

But more importantly: Learn from this and find a way to avoid it happening again. Retrospective meeting might be a good place to bring it up. I bet more user feedback might have something to do with it :)

Btw, congratz on your first sprint!

  • 1
    I disagree with your statement about avoiding it in the future. Client requirements are hard to capture because they don't really understand what they want and how that translates to the application. If you go down the path you are suggesting, you will create an adversarial relationship with them. I DO like the last sentence in that section though as it hints at delivery early and often. If the dev staff could have had a version of the feature earlier in the sprint, the PO could have shown that to the client and gotten the feedback earlier. Either way, iterating is king! Mar 9, 2013 at 13:35
  • 3
    @BrianDishaw I really think (and hope) you misunderstood what I said/meant. Let me rephrase: "Get more user feedback during the sprint so you can adapt and avoid having to face this awkward situation at the end of the sprint, when you it's to late to do anything about it." Mar 9, 2013 at 17:22
  • Thanks Martin and @BrianDishaw for your responses. We'll look into how incremental "glimpses" of functionality for the users might be incorporated to help clarify requirements as the sprint moves along rather than a big BANG at the end-of-sprint demo. Of course managing a balance so that the "goal post" doesn't keep moving during the sprint.
    – Doug Ayers
    Mar 10, 2013 at 0:28

I would definitely vote for having a new story. Unless your Definition of Done includes that the client accepts it, regardless of the acceptance criteria, you are looking at new requirements and I would want to track and prioritize the new changes separately from the original story.

For example, they may want to tweak Story A that you just finished, so you create Story X. However, you don't want to tackle Story X if the client would rather move on and get a new feature with Story B first, and deal with their tweaks later if there is time.

Having separate work items allows for this separation of prioritization.

  • Good point; I like being able to separate the new tweaks from other stories that may now have higher priority
    – Doug Ayers
    Mar 10, 2013 at 0:18

A lot of it depends on large the changes are and how high a priority the tweaks are. Will the client accept the feature as is knowing it will be changing next sprint? Will they not accept the feature as is?

The answer to those questions will drive what you do next, A or B.

As for the estimation, I would be careful about losing your original estimation. If you lose the original estimate, you will have a hard time figuring out your actual velocity for any sprint where you have to change the estimate.

If you use a tool like JIRA that allows you to link tasks together, I would log a new task with the tweaks requested, link it to the other ticket and put it into this sprints backlog (assuming you are working on it as part of this sprint).

Otherwise you could put a note on the original ticket with the combined story point value.

I have to commend you for your attitude about change. If you aren't able to accept it and figure out how to make your process flow with it, you will always be having retros about how you can plan more in order to ensure you don't miss anything again. I find that you will always miss something and the better approach is getting the feature in the clients hands early and often and then doing exactly what you are suggesting you do, Iterate.

  • "I have to commend you for your attitude about change." Thanks! Doing iterative development and understanding we will make tweaks as we demo to the user has helped us accept that change is inevitable, rather than delivering in 8 months and cursing when they want changes and undoing lots of effort.
    – Doug Ayers
    Mar 10, 2013 at 0:13
  • New feature: new story
  • Enhancement: new story
  • Defect: bug against original story

The important thing is that in an agile methodology we want learning and change but we also want this controlled. By creating a new story this will have to be put into your backlog and have to be priortised.

This is important as it will allow you to - show progress, i.e. it will properly reflect in your burnups / burndowns - will drive scope and allocation of effort

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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