Sprint Commitment Disagreement

So I would like to have some talking points as to why this is a less than an ideal practice. 

@Mike Davis, Well, it looks like the folks you are working with are more focussed on outputs than outcomes. In that sense, it appears you are not using Sprint Goals to focus on what each Sprint should accomplish. Experience is showing something to all of you but clearly no one seems to want to take actions based on what is known. Also, why are the PO's assigning work? How would it be different if the Development Team decided how much they can accomplish based on the objectives the PO has? How would this collaboration change the team dynamics that exist currently?

I realize that the team should be selecting items from the backlog, but in this organization that is not realistic at this time.  So I would like to have some talking points as to why this is a less than an ideal practice. 

I suggest a different topic for conversation. What does the organization hope to get out of Scrum? Why is its implementation unrealistic, and what benefits are expected to accrue?

The fact that the Product Owners assign work to the team and are then OK with work rolling over between Sprints limits some of the constructs in Scrum around transparency and adaptation, and it's challenging to build any level of consistency.

I see two options.

The first is that you adjust your workflow so that at a Sprint Planning, the Development Team and the Product Owner collaboratively develop a Sprint Goal and Product Backlog Items that support that Sprint Goal, along with others based on the team's capacity. With sufficient time, the Development Team can get good at figuring out how much work they can take on and finish in each iteration, which can increase predictability. With process improvements coming out of retrospectives, you can find ways to improve quality or increase throughput. With proper Product Backlog management and refinement, you can begin to forecast options for what different orderings of the Product Backlog look like concerning delivering items that have been sufficiently refined.

The second option is that you can abandon the iteration cadence and move to a steady flow of work. However, this takes a great deal of discipline to ensure that your Product Backlog is well refined, you're regularly reviewing the work with stakeholders, and enacting continuous improvement. However, you no longer need to worry about unfinished work rolling over - it's done when it's done. You can use flow metrics to track expected and actual completion to help stakeholders understand when work will be done.

Either way, though, without a pull-based model, you'll probably suffer from the people doing the work not taking ownership of the work. Pulling work into the development process and then moving it through, in my experience, leads to an increase in the feeling of ownership of the person or people doing the work. Understanding the workflow, whether it's a continuous flow of work or timeboxed iterations, also helps the team feel less artificial pressure with regards to getting work delivered in an arbitrary window.

The Scrum Master has many opportunities to coach the team and facilitate events as per his/her own agenda.

The Scrum Master can talk to the Product Owner at any time to discuss the objectives and rules of Sprint Planning in Scrum (in a friendly manner) and mention the benefits of adhering to them. The Product Owner must accept that only the Developent Team can tell what can they deliver. So much that this is an explicit rule in Scrum. Moreover, this is not even a peculiarity of Scrum, even in a waterfall project the PM would ask the 'resources' to estimate their tasks. It is simply business logic: responsibility and decision making belong together.

If there are meetings for backlog refinement, a reminder can be part of the agenda: this is an opportunity for the Development Team to realistically estimate tasks.

During Sprint Planning, the Scrum Master can facilitate (lead) the discussion and walk through the 4 inputs of Sprint Planning, perhaps even projecting a diagram. Estimated backlog items, capacity and past performance indicates what can be delivered. The Scrum Master can ask the team members one by one whether they feel the Sprint Goal can be met.

The Scrum Master can ensure that the Daily Scrum is not a 'ceremony of 3 questions' but an event to inspect whether the Sprint Goal is still achievable, and how. According to the Guide, if the goal is not achievable anymore, the team has to notify the Product Owner.

The Sprint Retrospective is a good occasion to discuss the potential ways of improvement.The Scrum Master can add things to the agenda, e.g. to inspect why the team cannot deliver the forecasted increment. Poor planning? Unforseen events? Bad practices? There are multiple reasons why not meeting the Sprint Goal is a problem. It bears risk, the increment may not be inspectable, it reduces transparency, it may increase technical debt, it decreases the chances to establish velocity and estimate future progress, etc. We should rather ask the question what is the benefit of not delivering the forecasted items?

Hi Mike,

maybe you should focus on the sprint review. I sounds to me like a little bit like water-scrum-fall and the backlog is not really adjusted after the review with stakeholders. The PO could discuss possible sprint goals with the stakeholder in the review. 

If some work was not completed, the stakeholder will give feedback. Maybe the not done parts are not value-able anymore.

How are the reviews of your teams? (I hope teams because your wrote product owners)

Nils