The concept of the ‘user story’ is an integral part of the Agile:Scrum methodology.
A user story is delivered with two key mechanisms, a written paragraph that describes a capability in a product from the perspective of the customer or user and a conversation.
Depending on the tools and user story collation method user stories can be presented as lists but also as sticky pad notelets, index cards. Different proponents of Agile have different preferences.
The focus on the user story is the discussion and exploration around the story in a conversation rather than the detail in the story itself but even if you use a virtual index card like a JIRA item. Ultimately you should at the very least include the “as a user, I want…” together with the conversation and the test or acceptance criteria of what is to be delivered.
An elaborate user story delivered up-front can be useful but it can be laborious to produce and if it is very broad in its nature then it is more correctly described as an epic. Part of the discussion of the story can actually reveal nuances and elements to the whole aspiration for the product or feature that you may not have reduced to writing.
This is especially true if there are multiple user stories aggregated in the narrative or a collection of stories that hang together. If it is too verbose, can you be confident it will be read-through in detail and more importantly, understood, without a conversation?
All we wanted was a tire swing
One of the challenges that I see in the building of user stories and in fact the definition of epics too, is that if the focus is on purely the behaviour of the UI and the UX then things will likely not be very successful
If you do that, then your story is defining exactly what you want to be built – you’re prescribing the ‘how‘ to some extent instead of calling out the ‘what‘.
While I am not a great fan of ambiguity and a loose description, I do recognise that engineers and developers have their own ideas and concepts and bring an entirely different perspective to the table when compared with product and usability people.
The point in the development of any product is joint exploration and discovery of what is possible rather than simply churning something out and trying to get to the ‘ticked box‘ objective as quickly as possible. It becomes pretty apparent when you look at some of the products available in the market, when a design is elegant as opposed to simply functional.
This clever versus functional element can be true for the mundane as well as the innovative – we see this in almost every aspect of products. Was the product that was ultimately delivered part of the original requirement from product management, the market, or ideas generated by engineering?
