Creating User Stories For Product Owners – Part 2

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.

Small

Since Agile consists of short sprints, user stories must be small enough to handle within a sprint. User stories work like building blocks, with each story adding value to the product. With small user stories, the product can evolve over time, and stakeholders receive value quickly and more regularly.

In addition to being functionally small, user stories should be limited in text and detail as well. One or two sentences is plenty of detail for the team to create a working feature. Any more information than just what is necessary slows the entire development process with extra overhead. When explaining the concept for a user story, the idea should be short and simple.

Testable

When a user story can produce a definite pass or fail criteria, it is testable. Offering pass or fail conditions reduces miscommunication between roles. Developers and testers alike know what is expected of a feature, and clearly see whether it does what it was intended to do. Without this clarity, the team could waste time determining whether a user story is finished when they could be working on more features and adding more value to the product.

A user story should contain all of the work to make a feature work from start to finish. Backend changes must be grouped with their front end behavioral changes. Without a testable piece, a team cannot determine whether the changes have been successfully implemented. Plus, changes without adding features give no value to stakeholders.

As the backbone of Agile Software Development, user stories must be useful to offer value to a product and the team. This responsibility lies with the Product Owner. Whether the Product Owner writes the user stories themselves, or whether they allow other roles to write them, it is imperative that they only allow good user stories into the backlog. If a user story satisfies each of these discussed properties, it should give the team a good idea to work off of and to create a new feature for the product.

<– Continue Reading –>

Our Book Recommendations

We found these books great for finding out more information on Agile Scrum: