1

Development of planned user stories is complete. Testing is pending as a part of our Definition of Done (DoD). Can the Product Owner still accept new user stories for the Iteration? What are the scenarios to consider when adding or removing user stories to the current Iteration, and how should we account for this when measuring velocity?

2
  • we are using scaled agile framework with tightly coupled Definition of done where our user stories are blocked for testing and await approval from PO, past iteration closure. I understand that user story is a Boolean whether it is accepted or not but what to do in these scenarios with the story point deviation ( all the User stories are above described pattern in each iteration) need a suggestion to handle the story points Jun 26, 2023 at 13:54
  • I've added the SAFe tag to your question, but it's obvious from your comment that your company has implemented SAFe improperly or incompletely. You need to address issues like this with your Release Train Engineer right away, assuming you have one. If not, I hope your parachute is gold-colored.
    – Todd A. Jacobs
    Jun 27, 2023 at 23:14

3 Answers 3

7

TL;DR

You didn't tag your question with any specific framework, but "Product Owner" is generally related to the Scrum framework, so that's how I will answer your question. There are some minor edge cases, but in general the answer to your question is that "new work" is only selected during Sprint Planning, so regardless of when the Product Owner adds items to the Product Backlog there should generally be no impact to the current Sprint.

Accountability for Product and Sprint Backlogs

The Product Backlog

The Product Owner can accept Product Backlog Items for the Product Backlog at any time. While the whole Scrum Team generally participates in Backlog Refinement activities, when and how to accept items for that particular artifact is the Product Owner's responsibility. Remember, the Product Owner is a single-person role accountable for the contents and ordering of the Product Backlog. While that person can delegate or collaborate with others the Product Owner alone is ultimately accountable for how the Product Backlog is managed.

The Sprint Backlog

The Sprint Backlog is owned by the Developers. It represents the plan the Developers have created to meet the current Sprint Goal. Since the Sprint Goal must not change during an iteration unless the goal becomes obsolete and an early termination is declared by the Product Owner, new items from the Product Backlog should be considered as potential work for future Sprints, not candidates for adding post facto to the current Sprint.

Because the Sprint Backlog belongs to the Developers, the Product Owner cannot put new work into the Sprint Backlog, nor should any Sprint Backlog items be added by anyone but the Developers as they discover or decompose work needed to meet the Sprint Goal the Scrum Team defined during Sprint Planning.

Pragmatic Summary

In other words, it's up to the Product Owner to decide how and when user stories (or Product Backlog items in any format) are added to the Product Backlog, but the Product Owner may not add additional work items to the Sprint Backlog, change the scope of Product Backlog items already accepted into the Sprint, or modify the Sprint Goal in any way without collaborating closely with the Developers. The Sprint Backlog represents a plan with a singular goal, and Sprint Planning is the appropriate event for creating new plans or new goals.

The Product Backlog is a queue for future work, and that queue is selected from by the Developers during Sprint Planning in order to meet a singular Sprint Goal that contributes to the current Product Goal. As a general rule, this should happen only during Sprint Planning. Unless the Product Owner wishes the Scrum Team to abandon work in progress and restart the planning process from scratch then they should not move the goalposts while work is already underway. This is an important facet of Scrum precisely because it makes the cost of unplanned change visible to the Scrum Team and to the rest of the organization.

Don't set your process up for failure by treating ongoing changes to the Product Backlog as cascading changes to the Sprint Backlog. I will again stress that there are edge cases, but for the most part if you have to ask the question then the answer should be "new work can only be selected during Sprint Planning." Anything else is likely to lead to scope creep, lack of focus on a cohesive Sprint Goal, the inability of the Developers to commit to meeting the Sprint Goal, or frequent failures in delivering planned Increments on a reliable cadence.

0

Sprint starts with a fixed set of stories. You should not add new stories to the sprint in the middle of it. If the work is completed earlier than expected, then it means that the estimations are not correctly provided or there's something else affecting the velocity. This must be investigated at the retrospective and addressed for future sprint estimations.

0

Can the Product Owner still accept new user stories for the Iteration?

Yes they can, but it is not an ideal situation.

The issues with adding stories to an in-progress sprint include:

  • It may invalidate or disrupt the planning the team has done for the sprint
  • It may push the work in the sprint beyond the capacity of the team to deliver
  • Context switching to accomodate the new work may reduce the time available to deliver value
  • It may impact on other planned work which in turn may result in stakeholders being disappointed

I would say there are three common scenarios when work is added to an in-progress sprint:

  1. The story is small and has little impact on the sprint
  2. The story is medium sized and the team has to remove other planned work to accomodate it
  3. The story is large and the team is forced to replan or restart the sprint

how should we account for this when measuring velocity?

Velocity is a measure of the work that the team gets done in a sprint. If adding new stories during a sprint causes disruption then it is likely the team will get less done. This will then result in a reduction in velocity.

It may be tempting to ignore the reduction in velocity and treat is as unusual circumstances. However, if work is regularly being introduced to in-progress sprints I would suggest you accept the impact on the team's velocity and reflect this in your team's reporting. You might say something like:

The team's velocity has dropped from 25 points to 22 points as a result of work being brought in to in-progress sprints and the disruption this has caused.

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.