How do we prevent debates over whether changes to user stories are new work or bugs?

I will answer your question from the point of view of Scrum.

User stories may be captured weeks or even months before the sprint in which the work is done. But a user story is a simple one or two sentence description of the requirement. There will be few if any requirement details captured and nothing about the implementation. Because these stories are so simple they tend to have a long shelf life.

In Scrum we use a just-in-time approach to user story discussions. At the beginning of each sprint the team meets with the Product Owner during sprint planning. They run through each story they plan to include in the sprint and the Product Owner provides the details they need to do the implementation.

So it is only at the last minute that the discussion takes place and all the details are fresh in the team’s minds as they start their work.

Also, the Scrum concept of the Product Owner is that they are the primary source of all requirements. The Product Owner spends a lot of their time speaking with stakeholders and builds up a strong understanding of what work needs to be done.

The Product Owner is also available to the development team throughout the sprint. If there are any questions or clarifications needed then the Product Owner is on hand to answer them.

Finally, at the end of the sprint the completed stories are demonstrated at the sprint review. This is an opportunity for the Product Owner and stakeholders to double-check that the new features are as they would expect them to be. If they spot a problem then any necessary fixes are added to the product backlog.

Let’s block ads! (Why?)

Active questions tagged agile – Project Management Stack Exchange