SMART Goals in Scrum

The recommendation to formulate ‘SMART’ goals can be found everywhere in the literature. The SMART criteria are regarded as the gold standard for good goals. And now we come along in Scrum with user stories. What happened to SMART?

What are SMART goals?

SMART is an acronym that stands for five criteria for effective goals:

• S: Specific
• M: Measurable
• A: Accepted
• R: Realistic
• T: Timed

These five criteria are useful so that goals can be effective and are not just empty words or remain abstract. A negative example of a goal that does not meet these criteria is “We increase our sales”. A good example would be: “’We will increase our sales by 5% by the end of the year.’ Signed: the sales team.” The consistent use of “SMART” results in clear, measurable and verifiable goals.

And in Scrum?

In Scrum there are SMART goals, too – but this is only apparent at a second glance. Here we describe how the SMART criteria are implemented in Scrum.

Specific

In order to create goals that are clear and understandable, we use the user story technique in Scrum. A brief reminder: the term “user story” refers to sentences formulated in the form: “As a <beneficiary> I want <goal> so that <benefit>.” Goals in Scrum are the entries in the Product Backlog. User stories are useful because we do not only address the goal itself, but also its benefits and beneficiaries. This helps us to be more precise – alas specific.

So: “Specific” is addressed by the user story technique.

Measurable

The ‘measurable’ part of a goal are the acceptance criteria in Scrum. These are typically written on the back of the card where the user story is written on. If a certain acceptance criteria occurs repeatedly and refers to all or most product backlog entries, then we write it in the Definition of “Done”.

So: “measurable” is addressed by acceptance criteria and the Definition of “Done”.

Accepted

Because of its importance Scrum addresses ‘accepted‘ multiple times. Firstly, the Product Backlog is created jointly by the Product Owner and the team – in order to achieve a common acceptance of the entries. Secondly, the team is responsible for pulling the Product Backlog entries into the Sprint.

So: “Accepted” is addressed by a joint Product Backlog Refinement and by the team pulling Product Backlog entries into the Sprint.

Realistic

When pulling Product Backlog entries into the Sprint, the team checks whether the Product Backlog entry is realistically reachable in the Sprint timebox. The team also checks this by splitting an entry into tasks. Less obvious is the check of “realistic” in the Product Backlog Refinement. The joint discussion avoids that unattainable goals are included in the Product Backlog in the first place. By constantly inspecting and adapting, the point “realistic” is constantly re-examined in relation to what has been achieved so far.

So: “Realistic” is addressed by pulling Product Backlog items into the Sprint and splitting them into tasks.

Timed

A common criticism of Scrum is that Product Backlog entries are not timed. Nothing could be further from the truth. Timing takes place in several places. Timing is also subject to continuous inspection and adaption in order to improve the quality of time projections. When a Product Backlog entry is pulled into the Sprint, it is also timed: it means that the entry will be delivered at the latest by the end of the Sprint. On the other hand, the estimations and the measured velocity are combined for a date forecast. With the formula “sum of Story Points up to entry XYZ – divided by the average speed” a date forecast can be given for each entry. In contrast to wishful thinking, this estimation is based on actual data – and continuously improves with more Sprints and data.

So: “Timed” is addressed in the short run by pulling entries into a Sprint and in the long run by date forecasts based on estimates and measured velocity.

Conclusion

Scrum uses SMART goals. In combination with timeboxes and inspection and adaption it becomes especially effective.