Tell me more ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.
up vote 9 down vote favorite
4

I'm transitioning from a Project Manager to a Scrum Master, and I need to come up with some examples of SMART goals for the new role. The goals are for my Annual Performance Reviews where I will be assessed on 4 goals. As a project manager, I could say something like "I will lead and execute X projects on time and in full with 95% satisfaction." What goals would be appropriate for a Scrum Master role?

share|improve this question
1  
SMART criteria are not an explicit artifact in Scrum, and setting project objectives is usually the job of the Product Owner. Can you provide more context about your situation, and what you're trying to achieve? – CodeGnome Jul 23 '12 at 19:12
@CodeGnome Even though SMART criteria isn't a Scrum artifact, it might be possible to ask for specific, measurable, achievable, relevant and timeboxed goals for a Scrum Master as opposed to a Project Manager. Just because it's an acronym doesn't mean it's meaningless in another context. – Lunivore Jul 23 '12 at 22:06
1  
@Lunivore No one said you couldn't use SMART goals within Scrum, if you want to. The issue is that the question doesn't define a referent. Who are the goals for? The team? The Scrum Master? Some set of project deliverables? Context matters. – CodeGnome Jul 23 '12 at 22:27
@CodeGnome Well, she said - for the new role. Seemed clear to me. – Lunivore Jul 24 '12 at 10:14
@Cathy-B Try asking, "How, and when, will I know if I'm doing this role correctly?" It's the same thing as SMART and people get less hung up on acronyms. – Lunivore Jul 24 '12 at 10:15
show 4 more comments

2 Answers

up vote 9 down vote

Deconstruction of the Project Manager Goal

As a project manager, I could say something like "I will lead and execute X projects on time and in full with 95% satisfaction."

Setting aside whether this sort of goal really fits the SMART criteria even for a traditional project manager role, it is not appropriate for a Scrum Master role. Here are some reasons why.

  1. A Scrum Master provides process/framework leadership to the team, but does not "lead projects." The latter implies a form of command-and-control that is antithetical to the Scrum framework.

  2. A Scrum Master does not "execute" anything. (Neither does a traditional project manager, for that matter.) The team delivers the functional increments.

  3. With agile methodologies, increments are either "done" or "not done." You can't provide partial completion, and by extension you can't provide partial satisfaction. As a result, terms like "95% satisfaction" should be replaced by more concrete measures of "done."

Some Role-Oriented Suggestions for a Scrum Master

Here are some Scrum Master goals I've used for myself, cast as SMART goals. Perhaps they will be relevant to you in your new role.

  • I will consistently encourage the team to keep the daily scrum to 15 minutes or less every day, and will carefully review how the meeting is handled if it exceeds 15 minutes more than once per sprint.

  • I will strive for 100% visibility of all user stories, both from the product backlog and the sprint backlog, during each sprint.

  • I will ensure that zero new work enters the sprint backlog from outside the team during a sprint.

  • I will request that the Product Owner terminate the sprint immediately and reboot Sprint Planning whenever the defined sprint goal cannot be met.

  • I will actively encourage team members to use the daily scrum as a self-directed task coordination meeting, and will measure my failure rate by how many times two or more team members look at me simultaneously during the scrum.

These are my personal top five, but you can either adapt them to suit yourself, or use them as a guideline for developing your own criteria. I would certainly recommend using the Agile Manifesto as a guiding principle, and focusing on your ability to communicate about process when setting goals.

In my opinion, Scrum is all about visibility and enabling self-directed teams. As a result, your goals should certainly focus on communications and people more than anything else.

share|improve this answer
1  
This is very helpful; in reading and learning about Agile and Scrum, I agree with everything you stated in #1 to #3 - my mistake in not expressing it correctly about the execution is done by the team; the company is also in the process of adopting Agile methodology, so they are having a difficult time understanding that a project manager is different than an Agile release manager as some of the team are called now as well as different from a Scrum Master. I appreciate the assistance..this gave me a good base to think more on. – Cathy B Jul 24 '12 at 22:55
1  
I especially like your point #5. One of my toughest challenges has been to stop the daily scrum from becoming "Report to the Leader" and to get the team to see this as their meeting. – BenK Jul 25 '12 at 11:02
I think these are all valid goals but you do need to make sure they are truly SMART (i.e. specific, measurable, achievable, realistic, timebound). 100% and 0% targets are laudable but normally not realistic or achievable in my experience. The time element is also important - you can't really measure success against something if it doesn't have a limit for completion (just like in Scrum!) – Willl Apr 12 at 10:56
up vote -2 down vote

Simply put, you can't.

I wish this could be an answer, but there simply is no answer to be had.

Long term SMART goals (the form favored by corporate annual reviews), are in nearly every way antithetical to Scrum. The issue is that the SMART guidelines are nearly the definition of waterfall, everything Agile is meant to get away from.

When you're 3 months into a 6 month SMART goal and the business needs change...do you keep pressing on to complete your SMART goal (because your salary is dependent upon it), or do you abandon it for something else (best for the team/company)?

What metrics do you use? Most all the metrics of Scrum are best kept private, never shared outside of the team. Your team's velocity only has valid meaning and usefulness within the confines of your team. When it's exposed to the outside world (for example, via SMART goals) it becomes biased, tainted, invalid. It's no longer useful to anyone, a detriment to yourself, your team, and the business. Scrum metrics are deliberately arbitrary (Fibonacci scores, etc) and only relevant to the team itself.

Your goals are probably unique to yourself, not shared by the team. Additionally annual reviews imply a competition (picking "MVPs" from a team, etc). The result is it's not just about how well you achieve your goals, it's also how others failed to reach their goals. You now have a financial disincentive to assisting your coworkers, most especially your direct Scrum team mates since those are who you will be most directly in competition with. This cut-throat competition is in sharp disagreement with the core of all Agile methodologies which put teamwork and team bonding very high on the list (and competition no where to be found).

It goes on and on. SMART goals may have practical application on a sprint to sprint basis (effectively making a SMART goal into a backlog item or task), but as they're used in an annual employee review setting...they're incredibly damaging to the company and employees alike.

So what to do? Make up something with lots of buzz words and other BS that will dazzle the HR folk enough to get past their filter and move on with your job.

share|improve this answer
Do you have personal experience of SMART objectives causing the kind of problems you list? I disagree with metrics being kept private. True, not everyone will immediately appreciate what 'velocity' means but the goal of Scrum/Agile is not to set yourself up in opposition to your organisation - an Agile PM should be advocating for the value and importance of Scrum artefacts not hiding them. In my experience goals and objectives can be useful and do not need to lead to a 'competition' between staff - not least because, done properly, goals and objectives should be unique to the individual. – Willl Apr 12 at 12:46
1  
Scrum information should be highly visible. Backlog, burndown chart, etc. The velocity...absolutely not ever. Humans can't help but compare numbers and Group A will report a velocity of 50 while Group B will report a velocity of 200...despite the reality that Group A consistently delivers twice as much value. Goal uniqueness is the core issue with competitiveness: Collaboration can not happen because the team is not aligned. In all honesty, I have two experiences with SMART goals. Those detrimental ones I listed and no effect whatsoever as absolutely everyone thankfully ignored them. – Byron Brummer Apr 15 at 19:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.