1

The PO on a project shares his concern with the Scrum-master that it doesn't feel like dev team would be able to fulfill their commitment to deliver the PBIs selected during Sprint Planning. As a scrum master which action should I take?

Option 1: Tell the PO that no one tells the dev team on how to turn the sprint backlog into potentially releasable functionality. It is up to the Dev team to meet their commitments.

Option 2: Coach the PO on complex software development and tell her that the work (sprint backlog) emerges during sprint and so all the PBIs that were forecasted for the sprint cannot be completed everytime.

2
  • 2
    Hey there! In Scrum you can generate several statistics like a burndown chart. Do you generate those? They are more sophisticated than gut feelings and guesses.
    – hamena314
    Mar 10, 2020 at 7:56
  • I would like to know if the team has an ongoing process of not making the sprint. Because if it happens once in a while, there does not seem to be a need to make big changes. If if happens a lot that sprints are not completed you have some work to do. So could you elaborate on that bit?
    – Bart
    Mar 11, 2020 at 6:05

5 Answers 5

1

Can I suggest a 3rd option? This isn't just about coaching the PO, it's about coaching the dev team to have the skills to communicate to the PO (and others) why their selected Sprint Backlog is appropriate and sensible.

Although you're right that ultimately only the dev team can decide what's in the sprint backlog, that doesn't mean they shouldn't take input into those decisions from others, particularly the PO.

Discuss with the PO what their concerns are and encourage them to bring them to the dev team. Either the dev team should be able to set the PO's mind at rest, or they may realise they've not taken a factor into account and are actually in danger of not meeting the sprint goal. E.G. the PO may be aware a PBI is more complex than the dev team seem to be treating it, or have noticed that they've committed to significantly more items than they've previously successfully delivered.

You may also have a problem with artifact transparency. It may help reassure the PO if they can see an accurate depiction of the current state of the sprint backlog, so they can see if the team is on track to meet the sprint goal.

1

No option is fully correct.

Tell the PO that no one tells the dev team on how to turn the sprint backlog into potentially releasable functionality. It is up to the Dev team to meet their commitments.

This is only partially correct. Although it's true that it is solely up to the Development Team on how to turn Product Backlog Items into Increments of potentially releasable functionality, it's important to realize that Development Teams also do not commit to completing Product Backlog Items during a Sprint. Development Teams - really, everyone on a Scrum Team - commits "to achieving the goals of the Scrum Team". On a Sprint level, the goals of the Scrum Team are expressed in the form of a Sprint Goal. Therefore, it's safe to say that the Development Team commits to the Sprint Goal.

Coach the PO on complex software development and tell her that the work (sprint backlog) emerges during sprint and so all the PBIs that were forecasted for the sprint cannot be completed everytime.

This is also only partially correct. It's true that software development is a complex task and work may emerge during the Sprint. The entire Sprint does not need to be fully planned at Sprint Planning and it's likely that the Development Team will learn more and adjust the Sprint Backlog as the Sprint progresses. However, I would suggest that, over time, the team should get better at being able to forecast the amount of work that they can get done within a Sprint timebox. It may not happen 100% of the time, but if the team isn't getting better at expressing their confidence in achieving the Sprint Goal and completing the work at the Sprint Planning, that is a skill that may need to be developed.

Ruaidhrí Primrose's option is also partly correct:

This isn't just about coaching the PO, it's about coaching the dev team to have the skills to communicate to the PO (and others) why their selected Sprint Backlog is appropriate and sensible.

Not only should the Development Team make their Sprint Backlog transparent to stakeholders (including the Product Owner), but they should be able to communicate why the Sprint Backlog is in the state that it is in and why they are making the decisions that they are making. Often this should be in respect to the Sprint Goal.

However, I'd present yet another alternative. In addition to coaching the Development Team about managing their Sprint Backlog, I'd also suggest coaching the Product Owner in crafting a Sprint Goal. The Sprint Goal is the objective of the Sprint that can be met by implementing selected Product Backlog Items. However, I suggest to teams that the goal should not be to simply complete a set of items but the outcome of those items - the team may be able to fully or partially satisfy the goal without completing all of the Product Backlog Items selected for the Sprint. I also suggest that a team limit the number of Product Backlog Items that relate to the Sprint Goal - if the Sprint Goal requires implementation of more than 60-70% of the selected Product Backlog Items, there's not a lot of room for undiscovered work or unanticipated events before the team cannot meet the goal.

So, here are my recommendations on what to coach:

  • Coach the Product Owner on the complexities and emergence in software development.
  • Coach the Product Owner on developing a cohesive Sprint Goal. The Development Team may also need some guidance here, as crafting a Sprint Goal is a collaborative effort during Sprint Planning.
  • Coach the Development Team on how to ensure their Sprint Backlog is transparent and how to explain or defend it to stakeholders, including the Product Owner.
2
  • Thomas and Ruaidhri, thank you so much for your valuable inputs. You are right in saying that none of the two options is 100% correct. But this question came in an exam and I needed to select 1 out of these 2 options. From that perspective, which options out of the two is more appropriate?
    – Ravi Gupta
    Mar 10, 2020 at 13:51
  • @RaviGupta What exam did this come from?
    – Thomas Owens
    Mar 10, 2020 at 13:55
1

In 2011 the Scrum Guide was updated by removing the term “commit” in favor of “forecast” in regards to the work selected for a Sprint

You can read more about it here: Commitment vs. Forecast: A Subtle But Important Change to Scrum

The PO on a project shares his concern with the Scrum-master that it doesn't feel like dev team would be able to fulfill their commitment to deliver the PBIs selected during Sprint Planning.

The PO is under the wrong impression that the dev team has committed to deliver the PBIs selected during Sprint Planning. Complex software development has technology/requirement uncertainties that become clearer only during the sprint. So, Option 2 is the right answer that you should select.

Option 2: Coach the PO on complex software development and tell her that the work (sprint backlog) emerges during sprint and so all the PBIs that were forecasted for the sprint cannot be completed everytime.

0
  1. Any given sprint backlog is not a commitment to deliver - it is, as mentioned by another answer - a forecast. The "business" needs to understand that this is fundamental to the process.

  2. (which nobody seems to have mentioned) - if the team is repeatedly failing to deliver the sprint backlog, then there is a problem. Is the team using "velocity" to measure it's capacity, and is it taking story points into the sprint based on that velocity? If we assume that the team is stable and is comfortable with its estimation process, keeping your commitment in line with your velocity is a measure that gives confidence in the teams ability to deliver.

-2

Honestly, in all of the above responses I see too much of the word, "coaching." This is a word that implies that you are somehow smarter than the average bear. If the Product Owner is expressing the observation that the team might be biting off more than it can chew, try accepting that advice and reducing the number of items that the team tries to attempt. Ask the PO to explain his or her position to you, and listen. Assume that s/he knows exactly what s/he is talking about, and is 100% correct. If you try instead to "coach" the PO, it means you're not listening and/or that you don't seriously regard what s/he is trying to tell you.

Any development team is, of necessity, very close to what they are doing. Their point-of-view is "inches away, if that." They carve out a set of tasks into a "backlog" not necessarily knowing, until they actually get into it, what the actual work might turn out to be. An outside point-of-view such as the PO's therefore gives a perspective that they might not see. Your position as SM is also much closer to their point-of-view than the PO's, so you might not be seeing it either. The PO might well be telling you something that you need to seriously listen to, accept, and act upon.

2
  • 2
    Coaching is absolutely the right term to use. In your first example, the coach wouldn't make the team reduce the work brought into a Sprint, but coach the team on how to better forecast what work can be brought in, better sizing of the work, techniques to slice work into smaller (but valuable) chunks, etc. The idea of a Scrum Master (or any other coaching type role) making the team do something, rather than explaining the benefits and risks and letting the team decide what to do and how to do it, is indicative of a command and control approach that is inconsistent with Lean and Agile methods.
    – Thomas Owens
    Mar 10, 2020 at 15:14
  • I'm speaking more about "coaching" the project owner. Yes, Lean/Agile prefers a lassiez faire management style and there's nothing wrong with that, but the project owner is effectively the Almighty Customer. Mar 11, 2020 at 18:59

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.