Of Babylonian kings or why technical users in user stories are OK

Every time a technical system impersonates a human in a user story, God drowns a kitten in an agile waterfall.— Unknown

User stories are supposed to advocate the user’s view on a system’s behaviour. Whatever technical systems which interface with “our” system think or do does not interest us. But why then is it so tempting to write user stories from an external system’s point of view? Because the system deputises for a user, it acts in the user’s interest and on his behalf.

 

The master plan in the grand scheme of things is concerned only with requirements for human users which may lead to the discovery of unnecessary or contradicting requirements; and once they have been identified, an entire cascade of systems can be simplified and whole systems can be removed from the equation.

Imagine finishing a two hours workshop, writing down complicated validation requirements for an exotic credit card type, just to find out that none of the system’s customers actually use that type of payment:

Requirement: as an ATM, I want to be able to submit ACME credit card numbers which consist of Babylonian numerals.

 

Example of Babylonian numerals. Source Wikipedia.

If we challenge this requirement, we’ll have to take it up with the ATM implementation and the ATM functional requirements. Ideally, the ATM people will realise that this requirement is unimportant even to them and there is no need to percolate it through to our project. Less ideally, the ATM is untouchable and “out of scope” and we’ll just have to live with that weird requirement.

Taken to the extreme, the master plan will not stop at questioning the necessity of individual systems or technical processes; no, it will revisit entire business requirements and eventually advance into the spheres of existentialism, questioning the purpose of business as a life-sustaining endeavour and maybe life itself.

While questioning everything is sometimes the honest thing do to (which may have had prevented many doomed-to-fail projects from ever setting off), instead we’re often stuck in local optimisations: we don’t control external systems, the project’s scope and budget don’t cover extensive changes or organisational/political reasons prohibit us from altering anything but the system at hand (“just do what you were told”).

Mathematics is full of examples where a result can be achieved with different computations. E.g. the rather simple inverse of a square can be computed with a Taylor series:

I can compute the inverse square very easily, if I know how to perform divisions. I can also compute the inverse square with an outstandingly laborious process (casually summing up to infinity) which doesn’t, however, require me to know how to perform divisions. Had the product owner formulated a requirement to sum up a large (albeit finite) number of components and I were to implement the requirement true to the word (Domain-driven design, anyone?), I might have ended up with a slow and numerically imprecise algorithm. The “right” solution (namely implementing the analytical function instead of the expanded series), requires me, however, to understand the requirements better than the product owner (I’ll omit the obvious objection why one wouldn’t challenge the functional requirement in the first place).

In an ideal project set-up with a large budget we’d be allowed to challenge user stories where technical systems substitute human users and trace the requirements back to a human user; if we don’t find a human user, then the requirement is most likely mute and can be omitted.