Friday 24 April 2009

'As a' as stakeholder, not actor

Dear Junior

The story formatAs a <> I want <> so that <> is quite well established within the agile sphere by now, and almost the standard format in Scrum. In a way it is a pity because even though I like the format, and use it myself extensively, almost exclusively, there is a risk that we are setting in the mould. I have even heard equivalents ofif you are not doing asaiwantsothat, you are not agile. I think we should be doing more experimentation, we should be avant-garde, not dogma. Nevertheless, well established as it is, I think it is misunderstood.

Old habits die slowly, and so old mental models. One old mental model is the one of theuse-case, where some actor performs some action, and the system reacts in some described way. The formatAs a <> I want <> so that <> can be used to describe a use case by inserting the actor in the as-a-clauseAs a(n) <actor> I want …”, where the I-want-clause often takes the form ofbe able to <GUI-enabled feature>. My point is that even if the format can be used in this way, it is not limited to that usage.

If we use the format to express enterprise value, we can express things likeAs a head of accounting department, I want nightly synchronizations and comparisons with our bank accounts, so that we early can catch failed sales. Barring that we know little aboutsynchronizations with bank orfailed sales, we can see that this is not a use-case: the as-a is not the actor, it is the person feeling the pain of this functionality lacking, and based on this way of expressing the story, it will be much easier to get the Head of Accounting to sponsor and promote the story.

Opening up this door we see that there are multiple ways to address other difficult stories. Expressing quality characteristics (aka non-functional requirements) can be done in the same wasAs a marketing manager, I want the system to be able to handle 100 000 new users registering the same evening, so that it does not break down when we run our successful advertising campaigns. You can also expresstech storiesAs a QA manager, I want the system to be put under continuous build with the tests run automatically, so that we early know if a quality problem arises. You can even expresssoft issues like trainingAs a Development Manager, I want all team members to get basic training on version control so that we get rid of all those merge-mistakes that we suffer. In all these examples, we have a stakeholder expressing something that would give enterprise value to their aspect of the development effort, thus something a team could estimate in effort and a product owner could prioritize.

Of course, we can now notice that theactor interpretation is just a special case where the stakeholder happens to be an end-user of the system.

When working with this format I have also found it helpful to drop thea inAs a. Phrasing itAs Head of …” makes it a little more succinct, and seems to give the stakeholder him/her-self a more direct bond when reading it. Phrasing itAs a Head of …” seems to be a little bit moredistant orobserving way, and does not (in my humble experience) to catch on in the same way.

So, obviously we are nowhere near the perfect format forrequirements, we should not restrict our formats unnecessarily, we should look for new way of using those we have, and we should definitely do more experimentation.



ps Mike Cohn has written some related blogs and was kind enough to point me too them. Check out Non-functional Requirements as User Stories, Advantages of the “As a user, I want” user story template, and Writing User Stories for Back-end Systems that muse on adjacent themes.