User Stories

Correct Answer: The team should negotiate with the Product Owner to possibly descope or break down the user story.

In Scrum, adapting to changes and collaborating are key. When a story is found to be complex, discussing ways to manage it, like descaling or breaking it into manageable parts, is essential. Adding more team members (Brooks's law) or deferring hope to the next sprint without action doesn't solve the immediate issue and can lead to further delays. The third wrong answer misinterprets the purpose of the Sprint Review. It's about inspecting the increment and adapting the Product Backlog if needed, not a workaround for incomplete stories.

Correct Answer: The story is not considered done and it should be moved back for more work.

In Scrum process, a User Story is considered 'Done' when it meets the Definition of Done (DoD) agreed upon by the team, which usually implies that the functionality works as expected and is free of significant bugs. Therefore, if significant bugs are found during the review, the story is not deemed as done and should be moved back to the backlog for more work, making the answer 'The story is not considered done and it should be moved back for more work' the correct one. 'Ignore the bugs and keep the story as done' contradicts the Scrum principle of providing potentially shippable product increment after each Sprint, hence is not correct. 'Assign the bugs to a team member who did not work on the story' might not be an efficient solution as this member might not be familiar with the feature, hence making the debugging process slower, and this also violates the principle of collective code ownership in Agile practices. 'Create a new story in the backlog to handle the bugs' is not necessarily the best approach either - in Scrum, the ideal way to handle bugs is to fix them as part of the initial User Story itself, not as a separate story. This ensures that the Definition of Done is respected, and the team's velocity, or speed of delivery, remains accurate.

Correct Answer: The team should iterate on the User Story with the Product Owner to refine and establish clear and measurable acceptance criteria before starting development.

It is crucial for a User Story to have clear and measurable acceptance criteria before development begins to ensure that the team and stakeholders have a shared understanding of the requirements. The correct approach involves collaborating with the Product Owner to refine the story until these criteria are established. The wrong answers suggest proceeding without this clarity, which can lead to misunderstandings, rework, or the development of features that do not meet the stakeholder's needs.