Valuable
To be valuable, a user story must contribute some information or idea to a project that improves the product for specific role or duty. Teams may try to create user stories by saying, “It would be nice if the product could [feature].” The problem with this type of thinking is that the suggested feature may not be useful for a particular type of user. The idea sounds nice on paper, but no users of the product actually need it. If the team spends time creating this feature, they have contributed no real value to the product.
User stories must be unique to be valuable. The team could write several different user stories for each individual role that might use the same feature, but the end result is the same as if the team had just written a single user story for that feature. The Product Owner must filter out or combine user stories that serve the same purpose, with only minor differences between them.
Clearing up technical debt, while a necessary part of software development, does not constitute enough value to warrant a user story. The point of the user story is to deliver value to the stakeholders. Addressing technical debt may improve code performance and make it easier to maintain, but this does not give value to the end user.
By following the user story form that requires a role, a feature, and a reason, the Product Owner can know that this feature will add value. The feature will service some need that a role or user definitely has. Because of this, the team will have improved the product once the user story is finished.
Estimable
If a user story is concrete enough to get an idea of how much effort it will require to complete, it is estimable. Estimates do not have to be incredibly specific, a general idea in the form of story points is close enough. If a user story is too large to give an estimate, the Product Owner should split it into multiple individual stories. Estimating user stories allows the team to know how much work they can accomplish in a single sprint. Without estimates, user stories may span across multiple sprints, or leave team members without work if they finish very quickly.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: