No customers

Here’s another story pattern I often see;

As a business I want [goal] so that [value]’

Not identifying the stakeholder introduces a couple of barriers to delivering software.

Arguably the most significant is that you have missed the opportunity to learn something about the business.  Understanding the context  improves our ability to deliver software quickly (and therefore be more cost effective).

Reducing our ignorance and gaining a better understanding of our customers can only improve our effectiveness of delivering software.

Developers are not customers

I’ve been on a number of projects that used ‘Technical’ user stories. One incarnation of the ‘technical story’ I saw on a recent project was the technical debt story.  It went something like this;

‘As a developer, I want to handle exceptional cases, so that the software it resilient’

With a little digging it transpired that the previous iterations stories had been developed without accounting for possible failures due to unavailable resources (networks, databases etc).

The often quoted definition of done is ‘The simplest thing that works’.  Dan North elaborated this as ‘…with a sustainable eco-system…’ [of code].

So it seems to me that these developer stories existed because the previous stories had been completed without this sustainable foundation.

As developers, we are being paid to produce software (by our customers).  Therefore, any story that has the developer as the role should be viewed with suspicion.