How to write User Stories developers will love reading

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:

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. Testing `nodejs` Applications Book Cover

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.

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