Feedback in sprint

If there is a delay in getting feedback from the PO, what do you think the risks might be?

Posted By Ian Mitchell on 02 Mar 2016 10:11 AM
If there is a delay in getting feedback from the PO, what do you think the risks might be?

I don't see any risk in retrieving feedback during the Sprint Review. But on the other hand, if you're delivering complex increments and during the sprint you're not 100% sure if it is correct, it can be better to get the feedback asap.

But on the other hand, you may also learn more about a story and eventually make a story "bigger" than it initially was.

As soon as possible, based on availability of the team and the Product Owner to review the completed item.

Think in lean terms around the waste of "waiting". Is it preferable to batch items up and wait until a set moment (Sprint Review) in order to present completed items to the business, or is it preferable to present items when they are completed, which not only shortens the feedback loop, but also creates positive opportunities to address feedback in the same sprint.

Certainly, if any changes suggested are large and would jeopardize the sprint, they should be addressed in a separate story in a future sprint. However, if the changes are small enough to manage in the remaining sprint time and do not place the sprint at risk, why not address them then and there?

Don't get hung up on a story ending up larger than first thought. That can happen at any time in the life of a story, and can be a good topic for discussion at the retrospective (did the team miss anything when grooming?).

Certainly, if any changes suggested are large and would jeopardize the sprint, they should be addressed in a separate story in a future sprint.

What if the PO now see new opportunities and don't want to wait till the next sprint. He demands that this "new" story is done in the sprint even if it means that some lower prioritized stories will be removed from the sprint.

> What if the PO now see new opportunities and
> don't want to wait till the next sprint. He
> demands that this "new" story is done in the
> sprint even if it means that some lower
> prioritized stories will be removed from the sprint.

In Scrum, nobody can force any work onto the Development Team. A Product Owner is not in a position to make the "demand" you are suggesting.

What PO can do, however, is cancel the Sprint when the Sprint Goal becomes obsolete.

Do those new opportunities cause Sprint Goal to become obsolete?

I have an article on this subject:

http://www.scrumcrazy.com/Worst+Practice+-+The+Sprint+Review+as+a+Signo…

Posted By Ian Mitchell on 02 Mar 2016 03:48 PM
> What if the PO now see new opportunities and
> don't want to wait till the next sprint. He
> demands that this "new" story is done in the
> sprint even if it means that some lower
> prioritized stories will be removed from the sprint.

In Scrum, nobody can force any work onto the Development Team. A Product Owner is not in a position to make the "demand" you are suggesting.

Sorry, demanding is perhaps a bit too extreme...

Lets say the team is working on a very complex software. So complex that what is discussed during the refinement and sprint planning meeting doesn't always need to be right. Let say during refinement and sprint planning the team created a plan to deliver story A. For the sake of argument lets say its a login screen with red background.
Now during the sprint the PO tells the team that he wants a green background. Red is just not good anymore! now assume that changing background can take up to 4 days. (just an example)

Should the team continue working on the story with the red background or talk to the PO and change the scope of the story during the sprint and create the one with the green background?

Posted By Ian Mitchell on 02 Mar 2016 03:48 PM
> What if the PO now see new opportunities and
> don't want to wait till the next sprint. He
> demands that this "new" story is done in the
> sprint even if it means that some lower
> prioritized stories will be removed from the sprint.

In Scrum, nobody can force any work onto the Development Team. A Product Owner is not in a position to make the "demand" you are suggesting.

Here a more realistic example

Lets say the team is working on a very complex software. Complex as in creating certain workflows. The only thing the team knows is that workflows needs to be created but HOW these flows will go, that is something they will find out as they learn more about the product it self.

Now the team is working on story A. During the Refinement and Sprint Planning the team has created a plan as in how to tackle this story. All done, and the team has a certain direction. Now the team is working on the story and while they are working on it they found out that their initial workflow is functionally wrong. Technically its possible but functionally not correct.

The question is now: this new insight, do you take it to the next sprint or fix it in the current sprint as you know that your current story has no value anymore

> The question is now: this new insight, do you
> take it to the next sprint or fix it in the current
> sprint as you know that your current story has no value anymore

If the Product Owner is in agreement that the story has no value, then it should be dropped from the current Sprint and the impact on the Sprint Goal should be assessed.

Stories that have been found to have no value should not be included in the Product Backlog. The PO should identify new stories that *do* impart value to the Product. They may then be actioned at some future point and in accordance with a suitable Sprint Goal.

If the current work has no more business value, the PO can also ask to cancel the Sprint.
A brand new Sprint will start.
At the next retrospective, the Scrum Team will probably have insteresting discution about the impact of the canceling of the former Sprint.

Posted By Ian Mitchell on 03 Mar 2016 04:50 AM
> The question is now: this new insight, do you
> take it to the next sprint or fix it in the current
> sprint as you know that your current story has no value anymore

If the Product Owner is in agreement that the story has no value, then it should be dropped from the current Sprint and the impact on the Sprint Goal should be assessed.

Stories that have been found to have no value should not be included in the Product Backlog. The PO should identify new stories that *do* impart value to the Product. They may then be actioned at some future point and in accordance with a suitable Sprint Goal.

The initial story has no value anymore due to new insight. However, the new story (different workflow) does have value. We're not talking about an entire new story, but rather a slightly modified story.

Would this new story be added in the current sprint (replacing the older one) or place on the Product Backlog and wait till the team pull it in a sprint?

> The initial story has no value anymore due to new insight. However, the
> new story (different workflow) does have value. We're not talking about
> an entire new story, but rather a slightly modified story.

A User Story is a placeholder for a conversation about a requirement. That conversation will occur until either the requirement is satisfied, or it has been deemed unnecessary and removed from scope.

A change in understanding about the requirement is therefore to be expected. This change does not necessarily mean that there is a new story, as it may simply reflect the fact that there is an ongoing conversation about what the requirement means. A story would only be removed if there is no more value to be had in that particular conversation.

> Would this new story be added in the current sprint (replacing the older
> one) or place on the Product Backlog and wait till the team pull it in a sprint?

If the team find they can't deliver the scope represented by a story within the Sprint, then they should raise the matter with the Product Owner. Stories in the current Sprint can only be replaced if the Development Team agree to it. They own the Sprint Backlog and whatever is planned on it and forecast for delivery. If the story is not essential to the Sprint Goal, then there is no need for it to be actioned in the current Sprint. It can be estimated and prioritised on the Product Backlog for possible future delivery. If the story is essential to the Goal, then the team should try to reach an accommodation that still allows the Sprint Goal to be met and which avoids the need for the sprint to be cancelled.