Dec 31, 2019
Product Goals and Sprint Goals complement each other
If your Product Goals hurt your Sprint Goals, then it’s time to reconsider your imaginary version of Scrum
Mahesh Krshnan wrote an article with the title ‘Product Goals, not Sprint Goals’, where he claims that Sprint Goals are a distraction to delivering Product Goals. The article is reasonable, but the author is describing a Scrum-like implementation that is necessary to make its point. Using plain Scrum as intended cause its conclusions to break down. That’s why I decided to write a rebuttal.
I believe Sprint Goals and Product Goals are best buddies, like the two dogs below.
In this article, I will dissect his piece and show how Scrum is supposed to work in the different situations the author describes. I do believe many Scrum Teams work as he describes, so I understand why he draws these conclusions. But fortunately it’s something that can easily be solved by working in a different (and better) way.
I hope my article will help lift some Scrum Teams from the dark ages of their Scrum-like implementation. I’ve also included many references to help you do this, which is also why this article is a long read.
‘Product Goals, not Sprint Goals’ has 7 main arguments. I will try to show how each of them is not applicable to Scrum and the usage of Sprint Goals.
1. Sprint Goals treat Sprints as Fixed Price Projects
“By defining an objective for the Sprint crafted as a Sprint Goal and the Product Backlog items that, if completed would achieve the Sprint Goal, the scope for a Sprint is fixed at the beginning of the Sprint. As we should all know, fixing scope, schedule and costs is bad practice, as at least one of the three is bound to suffer.”- Mahesh Krshnan
If Scrum would fix scope, schedule and costs, then one of the three is indeed bound to suffer. However Scrum doesn’t fix the scope. The main purpose of the Sprint Goal is to make the scope of the Sprint flexible, while providing the Scrum Team with a north star.
For clarity: the Sprint Backlog consists of the Product Backlog Items selected to be delivered during the Sprint, plus the plan for delivering them. Here is what the Scrum Guide says about Sprint Goals, Sprint Backlog and Scope:
“Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.” — Scrum Guide
“The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.” — Scrum Guide
“As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint.”- Scrum Guide
As you can see, the scope and plan during a Sprint is flexible. So any claim that the scope or the plan must be fixed is hereby debunked. If scope or the plan is fixed then that’s because of how you decide to apply Scrum (and I would argue you’re not doing Scrum).
Further reading:
2. Sprint Goals Guarantee Occasional Failures
Failure impacts trust and morale. Sometimes not achieving goals that were agreed to, affects trust with stakeholders. It also affects the team is many ways. For instance, the mood and morale of the team members may be less jubilant when they haven’t achieved a Sprint Goal in contrast to when they did.” — Mahesh Krshnan
The point made is reasonable: by committing to a Sprint Goal you may fail. Failure may impact trust and morale negatively.
Working together on a clear and focused goal, whether it’s a Sprint Goal or Product Goal, promotes teamwork and has a positive impact on trust and morale. How you handle being unable to meet a Sprint Goal says something about psychological safety, not about the Sprint Goal.
The author agrees working towards a common goal is good:
“It is great to have a shared purpose when working as a team. In fact that’s what makes a team a team, rather than a group of people! “— Mahesh Krshnan
Not meeting the Sprint Goal is perfectly fine. We may have learned valuable lessons that set us up for success in the future. As long as we committed and gave it our best, not meeting the Sprint Goal is acceptable. It just means we encountered unforeseen complexity. There is no point in punishing this. There is nothing you can do prevent being affected in some way by the cone of uncertainty. You can’t abolish uncertainty completely, ever.
The safest alternative is not committing to anything. How does that help trust and morale? In fact, commitment is necessary to build high-performing teams, as explained by the 5 dysfunctions of a team model of Patrick Lencioni. And nothing you can do can prevent never failing anyway, unless you decide to not do anything at all.
Further reading:
3. Sprint Goals Promote Ebb and Flow, Creating Stress in Systems
If a team achieves a Sprint Goal too early in the Sprint, or if due to pressure they start estimating conservatively, taking on less for the sake of predictability, then there is unplanned slack, an unevenness in the flow of work, or to put it in lean terms, Mura.
One will also find that teams guided by Sprint Goals are under pressure toward the end of Sprints as they frantically try to meet expectations set at the beginning of the Sprint. This is Muri, again in lean terms, an overburden that we can and should avoid. — Mahesh Krshnan
Kanban is complementary to Scrum. You can use Kanban to manage your flow to prevent Mura and Muri. This is possible, because the scope is flexible and the Development Team is free to pull in or remove work as it sees fit, by collaborating and renegotiating selected Product Backlog Items with the Product Owner. Within the constraint that you should not put the Sprint Goal at risk by doing so.
Scrum has a Definition of Done to prevent quality issues, which is the same as a Kanban process policy. Except it’s just for the final state of the Backlog Item and not for any of the steps in between.
So if you love flow, just use Kanban together with Scrum to manage Muri and Mura. Scrum and Kanban are perfectly compatible. There even is an official Scrum.org Kanban Guide for Scrum Teams.
Further reading:
4. Sprint Goals Force Upfront Designs
The author claims the following:
“Although a detailed design is probably not the objective here, still an upfront design activity happens at the beginning of the Sprint.” — Mahesh Krshnan
He softens his own argument afterwards:
“This comes at a cost of emergence and agility, although it can be argued that the length of a Sprint is short enough to call this design, just-in-time.” — Mahesh Krshnan
The big assumption here is that the design needs to be finalized before agreeing to the Sprint Goal. That’s not the case. The work the Development Team needs to perform should emerge during the Sprint:
“The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.”- Scrum Guide
Sprint Planning just helps by providing a fallible and non-final plan that can be improved over time, instead of not making any plans at all.
Further reading:
5. Sprint Goals Force Work Breakdown Structures
“All the work needed to achieve the objective is figured out upfront, providing a plan to follow. This is a work breakdown structure with many teams figuring out task level details, dependencies, and even task level estimates, all for the purpose of monitoring progress towards the Sprint Goal, forcing the team to deliver to a plan.” — Mahesh Krshnan
The work and the plan is figured out just-in-time and may change and emerge during the Sprint. Meeting the objective (Sprint Goal) is more important than following the plan. There is some truth to this argument, Scrum does force you to make some kind of plan. But is that a bad thing?
I don’t believe making a plan is bad. Especially because it’s up to the team to agree how much plan and planning is good enough. So forcing to deliver a plan may be true, but it’s up to the team how much they plan.
If teams figure out all the task level details, dependencies and task level estimates up-front, that’s their choice. I would argue that Scrum does not force you to do this. I coach my teams to never do this as it’s a big waste of time.
Further reading:
6. Committing to Sprint Goals Necessitates Change Control
“If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint. — Scrum Guide
While “negotiate the scope” is left for interpretation, this still reads as change requests and approvals.
These negotiations with the Product Owner creates an ‘us versus them’ mentality. They are also unnecessary conversations that focuses more on how much is achieved in a specific time period, rather than on the product itself. This sends process kaizen, continuous improvement in process, down the wrong path.” — Mahesh Krshnan
The point about ‘us versus them’ is very valid. That’s why I think it should be more focused on collaboration rather than negotiation. So it’s once again up to how you decide to work together with the Scrum Team as a Product Owner.
Not discussing scope with the Product Owner also creates an ‘us versus them’ mentality, as the Product Owner is part of the Scrum Team. So I am curious to hear what alternative exists.
It’s good to discuss the scope together with the whole Scrum Team and the Product Owner is part of that team. So if anything, discussing with the Product Owner fits with a whole team mindset instead of creating an ‘us versus them’ mentality.
Further reading:
7. Sprint Goal Forces Delivery to a Plan
Finally, the team is forced to a project plan to live by for the duration of the Sprint, and an implicit promise to get it done.
Measuring progress against a Sprint Goal focuses on delivering to a plan. A team that can consistently achieve its Sprint Goals is not necessarily the best team or building the best possible product. This is a wrong metric to measure for progress. — Mahesh Krshnan
Meeting the objective of the Sprint, the Sprint Goal, is more important than delivering the plan. The team doesn’t commit to finishing the Sprint Backlog or following the plan, but to meeting the Sprint Goal.
As the Sprint Goal may be the same as a Product Goal or a part of a Product Goal, this is not a bad thing at all. If you achieve the Sprint Goal early, the team can pull in more work as it sees fit while managing the flow of work.
Further reading:
A. “The Sprint Goal … provides guidance to the Development Team on why it is building the Increment.” — Scrum Guide
Product Roadmap, Product Backlog and Feedback, (Not Sprint Goals), Give Guidance to Development Teams on why they are building what they are building. — Mahesh Krshnan
Using Sprint Goals doesn’t rule out having a Product Roadmap, Product Backlog or Feedback. The Scrum Guide is intentionally vague on how to do Product Management:
Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment. — Scrum Guide
It’s up to you to decide. Use that freedom. Scrum can only help make transparent what Product Management practices work and which don’t. It won’t tell you how to do Product Management.
B. “During Sprint Planning the Scrum Team also crafts a Sprint Goal.” — Scrum Guide
“If the Sprint Goal is crafted by the team during Sprint Planning, based on an Objective defined by the Product Owner, then the crafted Sprint Goal is merely paraphrasing the Objectives defined by the Product Owner.” — Mahesh Krshnan
You’re absolutely right. But the point of this flexibility is not to paraphrase, but to get commitment and offer flexibility to change it if it’s not feasible or valuable.
I don’t think forcing an objective by the Product Owner on the Development Team will lead to better results. The Sprint Goal is a commitment of the whole Scrum Team, and that’s why it needs to be negotiable instead of dictated by the Product Owner.
C. “Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month.” — Scrum Guide
Anyone who can successfully predict in software development is an outstanding oracle in the making. We may certainly reduce variability by reducing the scope and the schedule, in this case, a short time frame of one week to four weeks of a Sprint, instead of a six month or a twelve-month project. However, unfortunately, the Cone of Uncertainty still applies. — — Mahesh Krshnan
The foundation of Scrum is empiricism: more is unknown, than known. You should try to make decisions based on what is known. When the cone of uncertainty comes into play, you can adapt and use this information to forecast progress. A forecast, like any forecast, contains uncertainty. Scrum helps to reduce uncertainty but can never remove it. No development framework or methodology can do this.
But with Scrum you can be sure that each Sprint there should be a Product Increment that can be inspected, which reduces risk and uncertainty because something that works is delivered.
Further reading:
D. “The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives” — Scrum Guide.
The development team can work on one coherent function at a time without the functions having to take exactly the duration of a Sprint to develop. The development team continues on to the next coherent function, after finishing one. They do not have to work on separate initiatives at all. — Mahesh Krshnan
As explained before, less than a Sprint is good enough. If it takes more than a Sprint, scope may be adjusted. You can even set a stretch goal after meeting the Sprint Goal. Nothing forbids you from doing this with Scrum.
E. Sprint Goals Are Based On Sprint Duration
“These goals may each take different lengths of duration to achieve. These goals may not add up to, or each take the exact duration of a Sprint. In fact, these goals are not related to a Sprint in any way.” — Mahesh Krshnan
Sprint Goals are based on Sprint Duration to reduce risk and uncertainty. You can’t work on something for longer than a Sprint without having anything to show for. You must produce something that potentially can be released at the end of each Sprint, the Product Increment.
If you have a Product Goal that would take 6 months to build, Scrum would force you to break it down in smaller sub-goals, to minimize uncertainty and risk by delivering something sooner. How is that a bad thing? That’s what actually allows you to reduce uncertainty in the cone of uncertainty sooner.
Because Scope is flexible, they Sprint Goals don’t need to exactly take a Sprint. If you have more time you can pull in more work using the flow approach you are promoting. If you have less time, you can simplify the scope to meet the Sprint Goal. Then if you meet it, you can pull in more work as you see fit.
Key takeaways
- Sprint Goals and Product Goals are compatible and complement each other.
- Scope and Sprint Plan is flexible in Scrum, the Sprint Goal is not. The Sprint Goal helps to prevent meeting the plan becoming more important than meeting the objective.
- Sprint Goal is agreed upon by whole Scrum Team, to get buy-in and commitment from the whole team.
- Kanban and Scrum are compatible with each other, so you can use Kanban to improve your flow if you want.
- Commitment to a fixed Sprint Goal is a good thing. A Sprint Goal promotes teamwork, focus and collaboration. No commitment to anything is not a valid alternative. Commitment to goals is necessary for high-performing teams to become high-performing.
- Failure to meet the Sprint Goal is not something that should be punished, it’s something to learn from. Scrum doesn’t tell to punish teams when they fail to meet the Sprint Goal. If anything, Scrum shifts the focus to learning from it through the Sprint Review and the Sprint Retrospective.
Do you want to write for Serious Scrum or seriously discuss Scrum?
