Why does scrum.org say a good goal must be specific and measurable only, and not S.M.A.R.T. ?

Last post 11:02 pm November 16, 2020
by Eric Naiburg
1 reply
Author
Messages
08:38 pm November 16, 2020

The guidance is this, "In a complex world, a good goal is specific and measurable, but does not need to be actionable, realistic, or time-bound. It should not be assigned to people or a team as performance measures. Goals may change over time as the organization learns more."

However, this seems more like a very partial philosophy than something more widely held. Even the question itself seems 'provocative' because it is tempting the person to respond with a widely accepted idea, that a good goal actually IS all these things. If you do a simple search on "a good goal" the first thing that often comes up is that a goal is SMART.

And moreover, how can you set a goal without any expectation that it could at least be realistic? Else, how could you evaluate anything? It could be argued that goals which are specific and measurable are also by default, actionable and realistic and sure, time bound too. But why bother being different and just accept the common SMART acronym?

Bottom line - the guys and gals at scrum.org seem to want people to accept a definition that is contrary to what is commonly understood, and I'm not sure why.

11:02 pm November 16, 2020

Hi Lee, I am not sure which goal you are referring, I am going to assume Sprint Goal or where exactly you got that specific definition.  The Scrum Guide describes the Sprint Goal as requiring SMART metrics for sure.

  • Specific - During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
  • Measurable - The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a "Done" Increment. At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.
  • Attainable - Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
  • Relevant - The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done". An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal.
  • Time-based - Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

That is a few thoughts directly from the Scrum Guide. I would also add that Scrum.org provides significant amount of resources that go much deeper than the guide including Evidence Based Management  and many other resources helping to teach people ways for creating and defining Sprint Goals.  

I hope this is helpful.