6

In a project managed using scrum framework, I've a situation where all tasks associated to a user story (feature) had been done successfully. No more code changes are allowed since testing is in progress and sprint is near to closing date. However, while testing and reviewing the product, I, product owner or another team members had come with some suggestions to same story.

How to handle these suggestions?

  • Should new tasks be created in the new sprint and linked to story in previous sprint?
  • Or should a new story created in the new sprint with new tasks?
  • Or there are a better practice for such scenario?!
Improve this question

2 Answers 2

Reset to default
8

I prefer creating a new story that then goes into the backlog. The story is usually something like:

"When using [feature we created in current sprint] I want to be able to do [x]"

Notice that I said it goes into the backlog, and not necessarily into the next sprint. Its something new, and needs to be prioritized against everything else already in the backlog.

New things are new things which are new things. They all go the same place, no matter when they were thought of.

Improve this answer
4
  • 1
    I strongly with the comments about this going into the general backlog. Things that you are working on right now always seem to have a higher importance than everything else. You have to put these things into the backlog and then re-prioritize the whole backlog, not just automatically put these new items in the next sprint.
    – Kent
    Sep 13, 2012 at 20:02
  • 1
    Shouldn't priority also take into account that the person working on this will have to spend time catching up if too much time passes between initial implementation and the new changes? It seems like this process could possibly stifle the momentum.
    – jmort253
    Sep 13, 2012 at 20:27
  • 2
    I don't think so. Priority should be based on the product owner's needs, not the convenience of the developers. The idea is to deliver the software that they want, not the software that is easy for us to make. Although I would say it is something to make the product owner aware of.
    – Andrew Clear
    Sep 13, 2012 at 22:45
  • 1
    @jmort253 Context-switching may affect the story point estimate assigned during Sprint Planning, but it is independent of a story's priority on the Product Backlog.
    – Todd A. Jacobs ♦
    Sep 14, 2012 at 12:14
5

If you are following Scrum then there are two options:

  • The Product Owner terminates the sprint and the modifications are reevaluated and new user stories are created

  • The new ideas become user stories for the next sprint

Additionally, I suggest a retrospective about the issue, because how come that the new ideas are not known at the planning meeting? It seems that something is changing or not clear in the background which needs to be sorted out soon.

Even it is tempting, don't change a committed user story. It will cause you too much trouble and the broken window effect will kick in: there will be another small change, then another, another... (and there is no such thing as a small change)

Improve this answer
1
  • +1 for referencing broken window effect as it perfectly describes the issue with changing a committed user story.
    – JohnJ
    Sep 14, 2012 at 16:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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