Dear Junior
The story format ‘As 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 of “if 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 the “use-case”, where some actor performs some action, and the system reacts in some described way. The format ‘As a <> I want <> so that <>’ can be used to describe a use case by inserting the actor in the as-a-clause “As a(n) <actor> I want …”, where the I-want-clause often takes the form of “be 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 like ‘As 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 about ‘synchronizations with bank’ or ‘failed 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 was “As 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 express ‘tech stories’ “As 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 express ‘soft issues’ like training “As 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 the ‘actor’ 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 the ‘a’ in ‘As a’. Phrasing it “As 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 it “As a Head of …” seems to be a little bit more ‘distant’ or ‘observing’ way, and does not (in my humble experience) to catch on in the same way.
So, obviously we are nowhere near the perfect format for “requirements”, 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.
Yours
Dan
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.