The quality of a product is completely dependent on the process of how it's built. Product development starts when a client specifies their requirements, and developing software requires the entire team to precisely define what that application is supposed to do.
This is a companion discussion topic for the original entry at https://blog.crowdbotics.com/how-to-translate-unclear-client-demands-into-specific-product-requirements/
How to recognize a bad user story?
That’s a great question. A bad user story can lead to unfulfilled requirements and miscommunication on both ends. Some common elements we’ve covered of a badly written user story are in the post are:
- A story is written from a product owner or client’s perspective.
- A story is written from a developer’s perspective.
- A story is too big or contains too many steps.
- A story has no value to customers or end-users.
- A story is highly dependent on other user stories.
- A story doesn’t share enough information.