Plan Product Backlog items of the Sprint Backlog at Sprint Planning
Let's imagine that it is Sprint Planning time and that we align about a Sprint Goal, and we commit to that rather than to the Product Backlog items of the Sprint. However, if we would plan much more than what we actually complete at the end of the Sprint, our predictability (with respect to everyone, specifically people/stakeholders outside the team) will be poor/"bad/to improve" - the opposite would be bad seen as well, and developers want to have something to work on when what they are currently working on is blocked/in test (of course, this could be improved as well).
At Sprint Planning, Developers are presented with some historical metrics (e.g. average velocity and average throughput, as well as a capacity based on Story Points adjusted after holidays) and, due to a mix of engagement/"more advanced" status of the previous Sprint items and gut feeling (and perhaps something else I am not seeing), they are going to inflate their forecast about their capacity.
As a Scrum Master, I think I should let the developers choose their way to forecast what could be achieved within the Sprint in terms of Product Backlog items of the Sprint, and that I should serve/help/lead them towards some good practices/considerations (even though there are no best practices, I feel that some practices could be considered "good to try" and "bad to try", would you agree?). Empiricism tells us that generally we just can't predict with precision (and making that understandable to everyone else is challenging). Correct me if I am wrong, but as far I understood, Cycle Time or Throughput or Monte Carlo forecasting are not really directly going to answer the plan/forecast question "what set of items could be finished within a Sprint"; items size vary and vary from Sprint to Sprint, so, despite what I've read so far against Story Points, I still believe that we could just stick to our average velocity and align on the fact that we could do more than that or less, focus to our Sprint Goal and deliver an Increment every Sprint.
I would love to hear all your suggestions/thoughts on this, thank you in advance!
However, if we would plan much more than what we actually complete at the end of the Sprint, our predictability (with respect to everyone, specifically people/stakeholders outside the team) will be poor/"bad/to improve"
I don't follow what you are saying here.
Why would the predictability be seen as poor unless the team did not achieve the Sprint Goal? The stakeholders should focus their attention on the Sprint Goal and reviewing the team's achievement (or failure to achieve) that goal is one of the focuses of the Sprint Review. Why would the stakeholders care, or even know, if the team had more work in their Sprint Backlog, especially if it was unrelated to the Sprint Goal?
The most important objective for the team coming out of Sprint Planning is to have a well-defined and achievable Sprint Goal with enough of a plan to give confidence that the Sprint Goal can be achieved. Understanding the specific Product Backlog Items that support the Sprint Goal and more detailed planning for implementing those PBIs is one way to achieve this, but there are others. Using throughput and cycle time can be effective, as can using velocity.
if we would plan much more than what we actually complete at the end of the Sprint, our predictability (with respect to everyone, specifically people/stakeholders outside the team) will be poor/"bad/to improve" - the opposite would be bad seen as well
How can anyone measure predictability in terms of what other people plan to do? Their plans are up to them.
Wouldn't it be better to gauge such a thing empirically, over time, in terms of what they actually do?
Correct me if I am wrong, but as far I understood, Cycle Time or Throughput or Monte Carlo forecasting are not really directly going to answer the plan/forecast question "what set of items could be finished within a Sprint"; items size vary and vary from Sprint to Sprint, so, despite what I've read so far against Story Points, I still believe that we could just stick to our average velocity and align on the fact that we could do more than that or less, focus to our Sprint Goal and deliver an Increment every Sprint.
Monte Carlo forecasting, cycle time, throughput will work on varying sized items and different number of items if your sample size is adequate. They are statistical analysis that take those variances into consideration. If you do get to a point where your team is started to be consistent, they get even better. I suggest you read the book "Actionable Agile Metrics for Predictability" by Daniel S. Vacanti to get a better understanding of how they work. These metrics will have some of the same issues you would get by using velocity based upon story points. The big difference is that velocity based upon story points is using estimates (i.e. guesses) made with the information available at the time of the estimate. As soon as work begins, those estimates are not longer valid because you gain more information. But cycle time, throughput and the data used by Monte Carlo analysis is based upon actual work completed so they can be a bit more reliable.
As @Thomas said, I do not see why stakeholders even care about those numbers. The stakeholders should be more concerned with the value that is being delivered to them each Sprint, and that value is identified by the Sprint Goal. There is no reason for anyone other than the Scrum Team to care about those items in the Sprint Backlog that do not directly support the Sprint Goal.
However, if we would plan much more than what we actually complete at the end of the Sprint...
That behavior is problematic in my opinion. It encourages work that is carried from Sprint to Sprint. Yes, the goal of a Sprint is to create an increment that satisfies the Sprint Goal and not to finish all the items in the Sprint Backlog. But this behavior impacts the teams ability to be predictable no matter what kind of metric you use to measure. Planning to do work that is not possible to be completed during the timebox can lead to the behavior becoming acceptable and can then spread to work that is needed to deliver the increment.
Thank you very much @Thomas Owens for your reply!
Let me answer the questions you've asked in order to provide a bit more context: "Why would the predictability be seen as poor unless the team did not achieve the Sprint Goal?"/"Why would the stakeholders care, or even know, if the team had more work in their Sprint Backlog, especially if it was unrelated to the Sprint Goal?" I guess that, predictability is seen in terms of output ("planned vs delivered"), which I suppose it should not: for this, the only cure to me is coaching on outcome mindset.
Thank you very much @Ian Mitchell for your comment as well!
"Wouldn't it be better to gauge such a thing empirically, over time, in terms of what they actually do?"
Fully agree. Unfortunately, sometimes some people indirectly might tend to "judge" and "influence" the way this is done by the team (IMHO they should be well coached too).
Thank you Daniel Wilhite, it does answer the question I had in mind when I opened this post!
I believe that coaching/teaching the stakeholders (actually, everyone) on this is crucial, yet hard, as it embeds the mindset shift from output to outcome. Here is my thought on all this, I would love to hear yours as well: may we conclude that "We do not commit to the Sprint Backlog because it is output based and we can just not be capable of making a precise plan upfront"?
"We do not commit to the Sprint Backlog because it is output based and we can just not be capable of making a precise plan upfront"?
Almost right but not quite. In the Scrum Guide's section that describes the Sprint Backlog you will see that the team commits to the Sprint Goal. The teams wants to deliver 1 or more usable increments of valuable work. The Sprint Backlog is made up of the Sprint Goal, Product Backlog Items chosen and the plan to deliver the Increment. It is much more than just the list of items that are expected to be worked on.
Think of the Sprint Goal as a commitment, and the selection of PBIs and the plan as a forecast of work required to achieve it. You'd commit to a goal rather than a forecast. That forecast may be inspected and adapted during the Sprint as more is learned.