Measuring success as an agile BA

A BA I know came to me a while back and expressed frustration of not having specific deliverables in a scrum project.

The typical BA deliverables of requirements spec, UAT plan, change management and comms plans have been replaced with ongoing processes rather than particular documents which represent milestones in progress.

To a large degree these milestones have been replaced by ongoing processes of capturing and refining requirements, defining acceptance criteria and running tests. You end up with many smaller incremental milestones instead of the big few.

I discussed he issue with him until he had talked through his issues sufficiently for his frustrations to be vented and for him to have identified an immediate plan for himself.

Yesterday he came to me and expressed thanks to me for pointing him in the right direction. (The joys of Socratic questioning – I hadn’t even known how I was helping.)

He had come to realise that his measure of success was the same as the developers; increments of working software that has been happily accepted by our project stakeholders.

That’s my measure of success, too.

There are other things I need to do to get this done. Documents and progress reports are a part of the toolkit. So are meetings and conversations with people.

We do these things so that the goals can be achieved. When push comes to shove you prioritise the things that most contribute to your goals. You don’t just follow the process.

Measuring the right things is a real trick, isn’t it? Making people see value in the right measurements is also an important thing to do. Breaking bad habits – in ourselves and others - appears to be part of the job we all face, as we continue to grow in our profession.

This reflection is making me realise some of the problems of the master-apprentice model that many of us learned our trade in. It’s great if you get to learn from a true master early in your career, but what if you are one of the many who miss this opportunity?