The Good User Story / Bad User Story Routine

The truth is that if you work with User Stories then there's a very high probability that you're committing a crime; not particularly because you're using it rather with how you're using it. I have witnessed these crime scenes several times and have been tempted to solve it only to be faced with resistance of the highest inertia. And then a few days back, my LinkedIn feed exploded with posts around "the importance of writing clear & detailed User Stories", all referring to Josh Darnit's 2017 "Exact Instructions Challenge"; and my heart sank.

If you haven't seen the Exact Instructions Challenge, do watch it, it's amazing:

However it isn't the video that bothers me it's the message people take (or share) from it that does; when it comes to User Stories, it's important to note that an Exact Instruction is literally the last thing you would want it to be. But this article isn't about teaching you what a good User Story is, there's a lot of material out there from User Stories Applied to INVEST that can teach this. My intent is to present my top 3 Bad & Good User Story contenders, some good practices, and a hope to not confuse you as I go about explaining these, so here goes nothing.

My Top 3 Contenders for a Bad User Story

1. Jira Stories: It's on the top of my list and for some reason it has become a vocabulary; every time I hear someone say they write / work with Jira Stories, a part of me dies inside. The problem with any software like Jira is that it has no limit to the text area for narratives and most people go to town with it. This makes it very easy to break the Small Principle. And many people only started embracing User Stories when a software like Jira came along which made it even more difficult to understand and imbibe the essence of Small. But there's an easy way to get over it; just use index cards and a readable handwriting for your User Stories before moving them to your software. With time you'll build the necessary muscle memory needed to get over this.
2. Writing Stories: This probably sounds silly, isn't User Stories written? Well, there's a lot more to User Stories than just writing it, especially if the one writing it carries a specialised role like a Product Owner or a Business Analyst. User Stories are more of a light-weight process than just a description of a functionality that will be valuable to either a user or purchaser of a system or software. In the words of Alistair Cockburn, it's a promise for a conversation. Writing a User Story is similar to breathing, it forms an essential part that's needed for its survival but there's a lot more that happens with a User Story similar to any living organism. User Story is a medium for information exchange and having it written ensures that the exchange can be picked-up where it was left-off; the act of conversation though is probably the heart-beat of a User Story and hence writing it is not everything and writing it in isolation is not the best at all.
3. Acceptance Criteria: Every User Story needs associated Acceptance Criteria, that's not bad; it turns bad when we stop at it. User Stories need supplements which are not essentially a part of it but needed none the less to clarify user needs. But hold on to your horses before you start relating this to the Exact Instructions Challenge, not everything needs to be specified as text. For e.g. if you need to communicate the UI design then show an image instead of specifying your Acceptance Criteria in clicks and scrolls. There's no specific list of supplements that every User Story needs so you can have one as needed e.g. acceptance tests, metadata, compliance rules, system constraints, UI designs, background, tech decisions & designs, etc all driven via conversations. Although a User Story is needed to be Small, the supplements can make it look huge; however a User Story is deemed Small iff -

• an index card can accommodate the Narrative and Acceptance Criteria
• it can be made ready for production in a week (or iteration)
• it is well understood (Ready) by the people responsible to make it Done for production

That last part is achieved through Acceptance Tests and that most certainly is needed for every User Story; what is NOT needed in a User Story is in-scope, out-of-scope, RAIDs (none when Ready), notes, user steps, and other irrelevant information that one may find in a Use Case Document. So as a rule, move towards Acceptance Tests.

My Top 3 Contenders for a Good User Story

1. Estimated Stories: Yes, I know #NoEstimates is a thing and No, by Estimated I don't mean the User Story needs a Story Point. Estimations have a unique characteristic that I admire, it helps in validating a Shared Understanding. Consider a team discussing a User Story and identifying its Acceptance Tests, at some point of time it makes sense to ask the estimates from the individuals in an unbiased manner (given the baselines for estimations have been established earlier by the team). It is safe to assume that wider the variance between the estimates the lesser is the shared understanding within the team. It's a good indicator to have in order to determine if a User Story is Ready for development. The same is achievable using #NoEstimates, just get a thumbs-up or thumb-down indicator to the question - "Can this be Done in a week (or iteration)? Have we identified all the Acceptance Tests?" - as long as the baselines for answering these have been established earlier by the team, you will achieve the same results.
2. Reusable Stories: In the current scheme of things, it is possible that user needs are fulfilled through multiple platforms, for e.g. a user can buy books from the Amazon Website as well as Amazon Android App as well as Amazon iOS App as well as Amazon Kindle as well as Amazon Alexa, and more. Although these may use different interfaces, the Acceptance Tests for these remain the same; that's the Reusable aspect of User Stories. Hence it is highly important that User Stories are not described as clicks and scrolls and voice commands rather by the acceptable end results desired by a user. Reusability also ensures that users receive similar if not identical experience on all platforms through which their needs can be met. So keep the interface out of User Stories for as long as possible and use supplements to reduce coupling.
3. Incomplete Stories: If you play a specialist role like a Product Owner or a Business Analyst who's accountable for managing User Stories then this one's going to get you in trouble with your team; a good User Story by design is always incomplete. This jaw dropping characteristic of a User Story is what makes me cringe when someone compares it to the Exact Instructions Challenge. Because contrary to the common belief, reducing the amount of instructions and relying on the expertise of the team to get things Done can yield much better results, as long as the boundaries are defined well. But there's more to it; being incomplete makes a User Story Negotiable which enhances conversations and brainstorming which leads to identifying better tests. This also enhances the self-organising nature of the team where individuals are trusted to decide the actionable steps needed to achieve the desired outcome; definitely better than a robotic programmer coding the steps written by a few. And the biggest one yet, it reduces finger pointing by bringing in Collective Ownership and Accepted Responsibility within the team. So much potential and so little to do, just leave your User Stories incomplete, why wouldn't you do that?

In Conclusion

These are merely a few characteristics out of many more that can make or break User Stories. It's neither to say that this is a comprehensive list nor to say that one User Story can fall in only one of these categories. These characteristics as a whole describe a Good or Bad User Story and the more you have them, the more your User Story inclines towards one type; I trust you to take care of these. For now, here's my version of the User Story for Josh Darnit's Peanut Butter and Jelly Sandwich Exact Instructions Challenge:

The Narrative is on the left, the Acceptance Tests are on the right, and beware - it's incomplete.