Plan for next Sprint changes after Sprint Review

> However, whenever our key stakeholder attends the Sprint Review, there
> is so much discussion (on a collaborative basis). This results most of the
> time in a backlog with many newly created stories on top which where
> never discussed during refinements.

Stakeholders can be invited to the Sprint Review at the Product Owner's discretion. However, they are not invited so they can start doing the Product Owner's job.

It's the PO who owns the Product Backlog and everything that goes on it. The Product Backlog is not owned by any other stakeholder. Moreover, it's the PO's responsibility to liaise with other stakeholders, including your key one, in a timely manner. This means that any input from this key stakeholder must be elicited *before* the review, so that the PO can take ownership of it, and work with the Development Team on refining appropriate Product Backlog items that will be ready for Sprint Planning.

So, where is your Product Owner in this situation?

Hi Benjamin,

We have (had) similar problems and there were several possible causes and solutions for us:

* The market changed and we had to adapt. We make apps for iOS devices and Apple can announce and launch new features on a single day. In that case we replan the sprint with the new insights or if we know a date we don't plan too much and plan the next part of the sprint when we know what possible new valuable items are. We sometimes switch to a method we call 'swarm coding' where we use a much shorter time box than a sprint - up to two days, usually shorter - and we come together every hour for three minutes and work all together on one item. This often works well for really unknown work like new technology or a weird bug.
* The PO and team failed to groom PBIs enough for them to be plan-able (often called "ready" or "definition of ready"). In this case, planning becomes a kind of grooming and planning session in one, with a lot of discovery during the planning session. We basically try to reserve some time during the sprint for looking ahead. Often it is possible to split work down into features or stories that are small and clear enough before sprint planning arrives.
* The business team communicates with the team without involving the PO or the PO is not empowered to decide about the product backlog. We solved this by being strict about all communication going via the PO. If the PO is away, the business team decides who temporarily takes that role.
* The PO lost connection with the team for some reason and only discovers where the product is during review. Before, our POs were away doing other things and sometimes only found out what the product would be at the end of the sprint. Combined with some lack of quality and testing, we would often discover new ideas and bugs during review. We now have a dedicated PO who is very available during the sprint. Also, the roles are clear - the business knows that new features and stories can be put to the PO at any time, not just during sprint review. The review contains very few surprises for the business because the PO is the most updated person on the teams. We also have unit tests and an automated deployment line that make deployment faster and testing easier so there is less chance of bugs.

The fact that you are running into new expectations at review makes me think of that last situation. Is your 'key stakeholder' also the PO? Is he communicating well with the team during the sprint, or only at the review? Trying to somehow get at least some of the Product Backlog Items in earlier and actionable sounds like it would at least partly solve your problem.

Hi,

thank you very much for the informative answers.

Let me explain our situation a little further.

The key stakeholder I mentioned is not the PO. However, he is the direct line manager of the PO and the guy he gets his requirements from. In fact, he's the head of the department and has the full support of senior management.

I understand the Sprint Review as a collaborative working session where everyone involved in the success of the product discusses what the next steps should be.

In reality the key-stakeholder then tells the PO what to do next. I know that's not the way it should be. However, I don't see any chances that the situation will change soon.

So all the refinement work is kind of useless if after the review the direction of the development changes that much.

We tried to introduce the concept of a definition of ready. However, if we would stick strictly to it, the team would not be able to accept any story...

Don't get me wrong, our Sprints are usually pretty good. What really annoys me is all the time we waste "grooming" during the planning meeting.

Do you have any further advice for me? Something I could try as a Scrum Master to make the planning more effective?


Thanks again for your help :)


Regards,
Benjamin

Support your PO as much as possible...

If everyone welcomes the input from your key stakeholder you could also simply change the way that you schedule your refinement meetings:
- schedule them earlier in the sprint (to have more time before the nex one starts)
- plan in a bigger timebox for the meeting itself (to simply have time to refine them)

> In reality the key-stakeholder then tells the PO what to do next. I know
> that's not the way it should be. However, I don't see any chances that
> the situation will change soon.

It can only be expected to change if the consequences of this shortcoming are made clear. If PBI's are being introduced during the Sprint Review, and refinement is deferred until Sprint Planning, then there may be insufficient time during Sprint Planning to accommodate this activity. The time-box must be observed and the important thing is to make sure that it is not exceeded. Allow 8 hours for a 1 month Sprint, 6 for a 3-week Sprint, or 4 hours for a 2 week Sprint. If that isn't enough for the stories to be understood, a Sprint Goal agreed, and a Sprint Backlog crafted, then don't extend the time-box. Make the consequence clear...the team will not be in a position to start development.

There are 3 legs to Scrum - transparency, inspection, and adaptation. It isn't possible to inspect and adapt unless you can see what you're doing, so focus on observing the Scrum rules and on getting transparency in place.