Conflicts between PO/DEV TEAM/CEO

Multiple things here, usually asking reflecting questions but you're looking for advice.

- As the Scrum Master, I would coach the CEO to work with the Product Owner, share his concerns so the PO can take this into account.

- The Sprint Goal does not change. Only when it becomes obsolete, for instance when the product is cancelled.

- Assuming that the Sprint Backlog is similar to the one initially formed in the Sprint Planning, why did he not share his concerns there?

- In case the Sprint Backlog changed during the Sprint itself, how did this change? Was there a collaborative discussion between PO and Dev Team?

- Looking at the current situation; I would have the Dev Team and PO inspect what still is needed to achieve the Sprint Goal and adapt the Sprint Backlog to reflect this. 

- It's nice that the CEO says the Dev Team has to do something, but ultimately the Dev Team is empowered to decide on how they do it and the PO is empowered to make the decision on order of PBIs. So it is not up to the CEO to say that the Dev Team should finish the remaining work, eventhough this disalignment has occured.

The ScrumMaster should facilitate a discussion between the CEO and the PO, because there is a lack of trust in the PO and a divergence of vision.



But ultimately, the PO has the decision to cancel a Sprint if the goal has changed unexpectedly, in order to adapt swiftly and to create a new Sprint with new Sprint Review + Planning  immediately. But it is in case of severe divergence of Sprint Goal. The PO has to see before if by changing a few PBI without endangering the current Sprint Goal, there could be some smoother transition to the next possible Sprint Goal, and of course communicate that to the Dev Team.

Whatever, the Sprint backlog items are owned by the Dev Team, and therefore, except if there is a cancellation of Goal, Dev Team must go through the Sprint, but maybe some items inside can be modified if it does not endanger the current Sprint Goal and will be more in accordance with next.

In the mid sprint PO says that Sprint backlog doesn't reflect the Sprint goal and asks to change either sprint goal or sprint backlog items. But the CEO says that though sprint backlog and sprint goal don't match, Dev team has to finish the remaining work. What the Scrum Master should do in this situation?

How does the Product Owner know that the Sprint Backlog does not reflect the Sprint Goal? More importantly, what do the Development Team think about that? The Sprint Backlog is their plan for meeting it.

Each member commits personally to achieving the goals of the team, and in respect of this commitment, a Sprint Goal does not change. Each Daily Scrum provides the team with a formal opportunity to inspect and adapt the Sprint Backlog, as needed, so the goal will in fact be met. These are the behaviors a Scrum Master ought to coach to the team and explain to stakeholders.

But the CEO says

The CEO has no role in the Scrum team. As SM, teach the CEO (and PO) that any input on the work to be done by the team, should go through the PO. you are actually empowering and helping the PO position within the organization here.

PO says that Sprint backlog doesn't reflect the Sprint goal

Who came up with the sprint backlog and sprint goal? PO should state and explain the sprint goal, and the dev team should plan a sprint containing the work that needs to be done to meet the sprint goal.

In the case the PO does not think it matches, as a SM, make the PO and Devs sit together and explain the goal and work to eachother. It can be that there ar assumptions or misinterpretations on any or both sides.

Ideally this is handled during sprint planning meeting and not mid sprint. If it did not happen during sprint planning, a formal and valuable moment to inspect and adapt is not used to its full potential. A learning for next time can be do to explicitly check if the PO goal is clear to the Devs and the planned is clear to the PO, so the planning outcome is explicitly accepted at the end of the sprint planning event.

All in all, for now, let the devs and PO inspect what goal is acceptable and feasible, given the expectations and demands vs the work already done. Throwing away done work will deliver no value at all, so maximizing value given the work already done seems the best approach. 

I don't fully understand how the Sprint Backlog cannot reflect the Sprint Goal.

The Scrum Guide states that the Sprint Backlog is "the set of Product Backlog Items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal". The Product Backlog Items were selected and the Sprint Goal was crafted by a collaborative effort between the Product Owner and the Development Team at the Sprint Planning. Depending on the team, at least a portion of the plan for delivering the Increment was also created at Sprint Planning, with the plan being inspected and adapted at the Daily Scrum throughout the Sprint.

The Sprint Goal should help the team select the appropriate Product Backlog Items. Likewise, the sizing of the Product Backlog Items can inform the team if the Sprint Goal is reasonable. I tend to recommend to the teams I work with that the Sprint Goal should be met without completing all Product Backlog Items. The goal could be related to a single Product Backlog Item, or it could be related to several. A rule-of-thumb that I use is somewhere around 60% - if you complete 60% of the Product Backlog Items (by count or by size), you should be able to meet the Sprint Goal. Should something come up during the Sprint - unexpected reduced capacity, unplanned or newly discovered work, or something else - the team is still very likely to achieve the goal. Other factors may play a role in this as well, though, and it's not a hard and fast rule.

I would find it extremely abnormal if the Development Team removed any Product Backlog Items from the Sprint Backlog without consulting with the Product Owner first.

As a Scrum Master, the first thing I would want to do is figure out why the Product Owner doesn't believe that the Sprint Backlog relates to the Sprint Goal and how it got into this state. I would also want to educate the CEO about the need to achieve goals rather than produce outputs, but I believe the more pressing concern is the Product Owner's understanding and visibility into the Sprint Backlog and how it is updated by the Development Team.

Here I am assuming that, the Sprint Backlog items didn’t change since the Sprint Planning.

Since entire team collaborates to decide on the Sprint Goal, it should be discussed with the entire team whether working on the current sprint backlog items is going to fulfill the Sprint Goal or not. If sprint goal seems to be in danger, Sprint Backlog should be adjusted immediately to achieve the sprint goal.

At the same time CEO should be coached that, working on the sprint backlog just for the sake of completing the Sprint should be avoided since it will not generate any value for the stakeholders. We should be able to adjust our work (Sprint Backlog item) as soon as the deviation has been identified.

At last, this must be raised as a concern in the Sprint Retrospective to avoid the similar scenario in the future.