Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

4 Answers 4

up vote 2 down vote accepted

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.

share|improve this answer
    
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 '13 at 0:20
add comment

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!

share|improve this answer
    
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! –  Brian Dishaw Mar 9 '13 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." –  Martin Wickman Mar 9 '13 at 17:22
    
Thanks for the clarification! –  Brian Dishaw Mar 9 '13 at 20:55
    
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 '13 at 0:28
add comment

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.

share|improve this answer
    
Good point; I like being able to separate the new tweaks from other stories that may now have higher priority –  Doug Ayers Mar 10 '13 at 0:18
add comment

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.

share|improve this answer
    
"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 '13 at 0:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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