In it, Barthes takes aim at traditional methods of literary interpretation, which take into account the author’s identity and personal, political and historical context in order to interpret and identify meaning within a text in a ‘definitive’ fashion.

Barthes posits that this is a fundamentally flawed approach given that we can’t truly establish an author’s intent within a work, and therefore a text must be interpreted in isolation, as if composed on a timeline that is not preceded or succeeded by an author, stripped of the limitations of context and isolated from any authorial ‘authority’. Essentially, the idea is that writer and creator are entirely unrelated to each other, and any literary work should be interpreted as such.

Further to this, Barthes also suggests that audience interpretation, rather than authorial intent, is the means by which a text can be ‘opened up’ and remain limitless in terms of meaning; how we read the text is key, rather than how we believe the author intended the text to be read.

Death of the author is one of my all time favorite literary critiques, not least because it suggests some radical ideas that had not been considered until this point, or certainly not articulated as such. It was a bit of a postmodernist middle finger to the literary elite of the time.

Exactly this.

This disconnect between author and meaning has become even more relevant as time has passed, as content platforms continue to make it easier and easier to publish material online. As self publication continues to grow in popularity, so too does the lack of context within which someone may stumble across your work online, devoid of context. Search engines make this almost an inevitability.

The user stories being constructed to feed our development teams are pretty much no different, and I think there’s a couple of things we can take from Barthes’ work and weave into our processes.

Know your audience

The key to any story is that your team have a clear, concise idea of what they need to deliver in order to meet a requirement. That might be different depending on team structure and maturity, and may again just differ dependent on team preference. Sure, there may be quality gates that as a story writer you want your ticket to adhere to (see: definition of ready), but that in no way suggests that there is a one size fits all approach or format to story writing which out of the box will satisfy every audience. Like your products, your stories should evolve to the needs of your team and be driven by their feedback. Some teams want scenarios, some teams don’t.

It’s important to remember when writing stories that your job is to provide information to your audience in the most easily digestible format as specified by them; your job is not to write the ‘perfect’ story based on opinions or standards that are not those of your audience (be they your own opinions, or ‘best practice’). The perfect story is one which your team can work with the most efficiently. And while we’re here; let’s put a swear jar on our desks for every time we catch ourselves dropping an acronym into a story.

This. LAZINESS.

Telling a compelling story is better than telling an overly detailed one

A story should be the means by which we articulate a desire, and a rationale for that desire. It should not be the means by which we compose sudo-code, or outline the technical implementation required to deliver a feature.

As a story writer, the job is to outline behavior and outcome: not how we achieve that. Leaving the implementation detail to the team allows that collaboration to occur in terms of how we arrive at a solution; our story should provide a compelling case for the implementation of a feature in the first place, which the team can get behind with a clear sense of purpose.

A story is dead once it is delivered

A story is a vehicle, a mechanism by which we translate information. As such, our tickets become irrelevant as soon as delivered, becoming a historical log of a requirement at a certain point in time, a timeline. We should always keep this in mind; our tickets define a point in time, and our codebase is our living documentation.

Our stories are the means by which we facilitate this transfer of knowledge into the codebase by way of automation tests, and we should treat them as such; let’s bear in mind that these are temporary tools and invest the appropriate amount of effort into their composition on that basis. On this note, it’s also important to consider how far in advance we compose them. As stories are temporal, they have a best before date; the more time between composition and being consumption, the more chance you have for them to ‘go stale’ and become irrelevant.

Irrelevant crisps. Also, you have to wonder what you’re doing with your life if you need to revive stale crisps in your microwave.

In my view, Barthes had the right idea. As story writers, we should always be mindful that our stories are serving the purpose they were intended for; our audience’s interpretation. Your stories are not really your stories, after all.