I recently finished the first draft of the new edition of "Agile Game Development." One of my reviewers commented that I still use the phrase "Sprint Commitment" after its removal from the Scrum Guide, but I left it in there.
One of the reasons that the phrase is no longer in the Sprint Guide is because it has often been weaponized to force teams to complete everything they'd estimated in Sprint Planning regardless of what problems emerge during the Sprint. This has resulted in teams compromising quality to get every feature in the game "done" by the end of the Sprint.
The Sprint Guide now uses the word "forecast" instead of commitment for Sprints, even though "commitment" is still a core value. I agree that forecast is an accurate way to express what the plan is, but I think we've lost something by dumping the word commitment.
It comes down to what we mean by commitment. Often forecast means "we'll get done what we get done," or better yet, "we'll do our best to get everything done, but we might have to drop some less important features." To me, commitment goes a step beyond that, but not so far to mean "we must do everything."
Commitment means doing our best to achieve a goal, but also being accountable as a team, when things don't go according to plan.
A good example is when you commit to picking up your child at daycare. You'll obviously do your best to be there on time, but sometimes things go wrong. Let's say your car breaks down a few miles away from daycare. Do you just say, "oh well, I tried my best"? No! You call your spouse, friend, and/or the daycare to let them know. You do this because you hold yourself accountable to pick your child up.
Similarly, if a team runs into problems with a feature in their Sprint goal, they need to hold themselves accountable. They need to raise the issue. They grab the Product Owner and discuss ways to address it. If they can't solve the problem themselves, they recruit the Scrum Master to help out. It still might mean the feature gets dropped, but the accountability results in risk being managed better.
Commitment is a core value for Scrum Masters to grow with a team. Sometimes the first step is to stop solving problems for the team and start asking them, "what should you do about it?"
I do not see a problem in the wording here. While the scope of the sprint is a forecast, entire Scrum Team still commits to achieve the Sprint Goal, as it is precise in Scrum Values - "People personally commit to achieving the goals of the Scrum Team.".
For me, this change of wording is a good thing, it shifts the gravity (commitment) to the place where it should be (Sprint Goal), and left flexibility where it belongs (scope of the sprint).
Thanks for commenting "Unknown".
I'm a bit confused with your wording, isn't the "scope" the same as the "sprint goal".
The guide uses "forecast" with respect to the "functionality" of the Sprint and the "work". I agree that the work is the forecast and, as a result, the goal is as well, but I think their attempt to avoid the weaponizing of commitment we see has watered down accountability.
As a result, I still teach "commitment" but clarify the aspects of forecast and accountability as you point out in the Scrum values.
What are some best practices you suggest SM and/or PO like myself should adopt to help guide the scrum team with forecasting during sprint planning.
I do not have an account here, so Clinton if you want, you can call me Peter ;)
I try to put it as short as possible:
for me Sprint Goal is the main purpose why we run Sprint, i.e our goal can be "Decrease friction in checkout to increase conversion rate", we even could add a metric if we want i.e "from 1.4% to 1.8%". As a whole team we collaborate what helps in achieving this goal:
- Implement online card payment service in checkout
- Implement one-click buy button
- Autofill promocode
- Make delivery date more visible
As planning progress, dev team forecasts what can be potentially included in anticipated increment, it could be that some part of this forecast does not even contribute to the Sprint Goal (maybe there is a little of maintenance?), or after a few days of work it can turns out that couple of PBIs are beyond our capabilities, or becomes irrelevant, or takes more time than we expected - but hey, We are committed to the Sprint Goal, we do everything what we can to achieve it, even if it means that we drop some not related but nice to have PBIs, even if we need to change some part of Sprint scope - that's the flexibility of forecast.
A more abstract example could be - my goal is to "pick up my child from school after classes", I am committed and accountable to this, but I also forecast that along the way I stop by for small shopping, post some packages in the postoffice, withdraw some cash at ATM etc. As time (Sprint) progress and I learn more I could drop something on that list, or replace with something other, or even add something as long as my goal is still in reach and not endangered by this not necessarily contributing to it elements of the (forecasted) plan (scope).
Maybe we are writing about same reasoning and we are almost on the same page, for me it is just a clear difference in using words "forecast" to work / functionality / scope, and "commitment" to (Sprint) Goal.
Hi Peter, Nice to put a name to the conversation!
I think we are close and I like how you describe what this team is doing. It shows a bit more self-organization and trust than less mature teams, but my thought in the post was to address more of the other end of the spectrum with teams that aren't at this level of maturity yet and follow the initial Scrum pattern as defined by the guide:
"The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog"
I saw the "pick up your child" as a PBI of a larger Sprint Goal containing multiple PBIs, perhaps the relating to the goal of getting all your spousal duties for the day complete. Analogies do have their limits though! ;) and so that part of the goal needed required a more committed response than just a "forecast".
I agree with your point that the guide says the Sprint Goal is a commitment with:
"People personally commit to achieving the goals of the Scrum Team"
I just wish it were more explicit as in:
"The team commits to achieving the Sprint Goal"
Again, this is less about nitpicking the Scrum Guide than with responding to what I see in the field coaching teams, but our conversation is helping me refine what will be in the book and how I communicate with teams...so thanks!
It depends on the team and what is currently happening. Does the Sprint Goal point to a clear increment of the product? Do they own their Sprint Backlog or is it being managed for them by the SM? Do their build practices allow them to see increments throughout the Sprint or is there an integrate/test "phase" at the end of the Sprint that hides true progress throughout the Sprint? Is the team engaged in Backlog Refinement or are they just presented with the ordered Product Backlog in Sprint Planning?
There are many conditions that lead to which practices to try. Feel free to contact me to chat about specifics:
While traveling towards the sprint goal we stop at one station for 15 min everyday to check how far we came and how long we have to go? Are we on time or our train (Sprint) is delayed... Based on that we decide anything can be dropped or picked up more..That’s why I always go with 60/20/20 rule to overload the sprint the goal is to must deliver 60 percent must have if time permits pick up another 20 percent should have still have room pick up another 20 percent could have.Having said that 20 percent should have could have is also must have in PBI but just loaded in the sprint as should have & could have if dropped it comes as must have in the upcoming sprint.This we don’t have to think last moment what we can add in the sprint since we have room also it helps to deliver more..
Clinton, you nailed it.
The commitment is one of the sore spots of scrum when it comes to real-life teamwork. As a scrum master, it is one of the top attributes which (for me) make the difference between a good scrum team and a "not so good" one. Other scrum masters might value velocity et cetera, but for me it is commitment. Why?
Because if commitment isn't given the value it deserves, then all the rest is lip service and not worth a penny, especially when it comes to being able to do predictable long-term (or more than 1 sprint) forecasting. Which is probably not a Scrum subject but very important when scrum teams are embedded in enterprise waterfall platform programs.
On the orther hand, what I feel extremely hard is: How to deal with teams which continously fail to deliver according to their commitment? There is no such thing as "punishment" (fortunately) and that makes it hard to make teams understand the importance of sticking to commitment.
But at the end of the day, if teams don't value commitment and perform whatever they feel like without consequences, it doesn't make a difference if they work in scrum or waterfall. All benefits of scrum are lost and scrum is worthless in the given environment.
Thanks for the comment.
You’re right, growing accountability/commitment is hard, especially for managers who have a quiver full of “compliance tools”.
To me it seems that what the team experiences in both planning and review can either grow a sense of commitment or harm it. It has to be their plan and the response to their achievement has to be based on how they’ve met the goal as a team. A lot of organizations “assign” goals and “measure” vanity metrics. Then they are surprised when teams don’t behave in a committed manner.
Post a Comment