Agile – How to Write ‘SMART’ Objectives as an Agile Developer

agilemanagementplanningreview

Like many corporations the company I work for is transitioning to a performance review system based on SMART objectives. My team is a high functioning agile development team employing practices from Extreme Programming. To our great benefit our employment of agile practices has the full support of immediate and upper management.

To accomplish work our team utilizes three week iterations. Beyond the immediate iteration we have a general plan laid out into quarters. Meaning that what we will have accomplished a few quarters from now is a lot hazier than what we will be accomplishing in the immediate quarter. We certainly have a general idea of where our project is headed, but the keyword here is general.

Given our approach to project planning members of my team, including myself are finding it difficult to write objectives which are specific, measurable, attainable, relevant, and time-bound (SMART).

Two existing questions on SoftwareEngineering.se do a good job of addressing some of our concerns:

However, the questions elicited more general responses than specifics for dealing with SMART goals when working on an agile development team. As an agile developer how do you write five to seven, year long objectives which are specific, measurable, attainable, relevant, and time-bound?

Best Answer

This answer is written from the perspective of someone who had such a performance management system put in place around an Agile team; like you, everyone on the team realized the difficulty/uselessness of year-long SMART goals applied to an Agile group, where, when fully functioning, the implementation of Agile can be considered inherently/already SMART.

No, really! Call the following a rationalization if you need to (if the logic is half-baked...), but explaining it to reviewers outside the immediate organization has set the stage for the actual "goals" we put in the performance management system.

  • S for specific: during each sprint planning, the team agrees on a specific set of tasks to achieve, and commits to doing them. The tasks (and the user stories), answer the questions of what do I want to accomplish, purposes/benefits of accomplishing the goal, who is involved, where it takes place, and constraints.
  • M for measurable: the list of these tasks, plus the movement of the tickets throughout the sprint, from development to code review to QA to release (or whatever your flow is), answers the questions of how much work and when will it be accomplished.
  • A for attainable: functioning Agile groups don't typically commit to something in the planning stage unless it is clearly attainable -- all the pieces are there to know how to accomplish it
  • R for relevant: questions like is it worthwhile, is it the right time, does it match our other efforts -- stories and tasks don't get pulled into a sprint, and committed to, unless the answer is yes to all these questions (typically...YMMV)
  • T for time-bound: a sprint is necessarily time-bound, be it 2 weeks, 3 weeks, more, or less.

If you understand/convince yourselves that your quarterly work (and thus your year-long work) is itself one big SMART goal, and that you know you're achieving your goals because the team is performing well, velocity is positive, releases are happening, then you get to the point of your question, which is ultimately how to translate a SMART process into a set of SMART goals for the benefit of someone else.

I've been able to do this successfully in the past by writing something that to me looks vague and, well, not very SMART, but is in fact perfectly acceptable for others.

A couple examples that have passed muster elsewhere for me:

  • "I want to release a new version of WidgetMaker every three months in the next year, by following our internal software development process, to align with the overall product development schedule (blah blah)."

  • "I want to increase the team's development velocity by n% from release A to release B, by focusing on incremental changes to the process of backlog grooming, in order to increase our effectiveness and decrease delays in shipping the product."

You know and I know that these are not the guiding principles of your actual development group, but they aren't wholly unrelated, and in my experience are the types of things that appear really SMART and useful to the people outside your immediate organization (without being outright lies or totally lame).

Related Topic