How to write User Stories developers will love reading

June 17, 2021

The idea to write this post stems from reading not-to-clear user stories from various sources and projects. Instead of prescribing what is right, or wrong, we will take a different turn and focus on asking questions about the nature of user stories.

If you don't already know, this article complements “How to write Test Cases developers will love”

At the end of the reading, you will have inspirations on how to make key improvements on existing user stories, or how to make them readable and easy to digest by developers who will be reading and implementing them.

In this article we will talk about:

Choosing the right user story based on ” As —, I want to —, so that —”
Choosing the right user story template based on GivenWhenThen
Choosing between user story and job story
The only template job story will need “When —, I want to —, So I can —”
Choosing verifiable acceptance criteria by developers and stakeholders

Even though this blog post was designed to offer complementary materials to those who bought my Testing nodejs Applications book, the content can help any software developer to tuneup working environment. You use this link to buy the book.

What to expect from a user story

When writing a user story, we will have to answer thoroughly following questions, yet in simple terms. The final product has to be mold our user stories have to fit in or template our user stories have to follow.

Why would developers hate reading our User Stories (hint: they don't, they hate the way user stories are written)
What should go into a User Story
What should not go into a User Story
Why does good messaging matter in our particular case. What is the definition of good messaging in our context?
How can we leverage acceptance criteria as a vector to reduce the bug count
What format are User Stories going to adopt
Or, in known User Story formats(JTBD/etc) which format makes sense for our use case
Why it is a good idea to give a say to developers when crafting a User Story
Why is it a bad idea to give developers a say when crafting or validating User Stories
How do we measure the performance of our new User Story template.

There is always a starting point. Instead of starting from nothing to answer these questions, It would make more sense to craft a typical user story(real user story), and test and answer questions based on a tangible example.

All criticism, or answers, should be targeted at making the user story at hand a little better.

Conclusion

In this article, we revisited how to write user stories that convey a clear message on what has to be done, in a way that developers may re-use the acceptance criteria as their test cases. As always, there are additional complementary materials in the “Testing nodejs applications” book that may be of your interest to.

References

#user-stories #bugs #bug-report #QA