Performance review 101, objectives should be SMART. Theoretically, SMART objectives make an awful lot of sense to me, but when asked to set objectives for a developer to cover the next 6 months it really doesn’t feel practical.
Normally, where I have a management problem, the agile community is a great source of inspiration and advice. It turns out that while it has little to say about performance review (why should it?), I’ve been using SMART objectives all along in the form of stories.
Let’s have a look at what SMART means and how it applies to stories.
By breaking down epics into manageable features it’s possible to isolate a small chunk of behaviour, such that all involved have a clear of idea of the scope of the problem.
Acceptance tests provide a clear means to determine when the story is done. In many cases the tests can be expressed in terms of ‘Given a set of preconditions, when a specific event occurs, expect the following behaviour’, this serves to reduce ambiguity and provide black and white tests to determine success.
Stories are estimated by the developers charged with their implementation. If the developers cannot see a way to approach the problem then it will not be possible to provide an estimate and the story cannot be accepted. At this point the story will either need to be broken down, or reconsidered before being re-estimated in its new form.
The story must in some way relate to the bigger picture, to do this stories refer to features recognisable by the customer as opposed to tasks recognisable only to the development team.
Working in time boxed iterations, or alternatively a work in progress limited flow, means that clearly defined expectations for delivery exist. Where these expectations are not met is is clear to all and it is time to discuss what went wrong.
I have a long held belief that one of the main reasons that the agile movement has been so effective is that it builds good management practices in from the ground up. SMART objectives in the form of stories are just one example.