As a developer, I love working on new features for my software project. New features bring value to the project, and if I’m speaking more ambitiously, more value to the world around me. Building features is immensely satisfying. That said, feature work isn’t always great. Sometimes I feel like I’m spinning tires in the mud trying to clarify details in the user story.
Usually, this is because the feature work is not well-defined. User stories that lack clarity in the details make me do work that doesn’t have this sense of value. When user stories are unclear and the work is not well-defined, it becomes difficult to predict when work will be done and have that value realized.
Describe the value gained.
A user story should clearly state what value this work will bring to the project. If the story is worth doing, there must be a clear purpose defined that will help drive the developer to finish the implementation.
The purpose of the story should be clearly stated as a goal. The goal should be a summary of what the end-user should experience after the story is complete. It should describe the business value (as opposed to the technical gains being made as a result).
You can call a story done if the gained value is realized in the deployed implementation. The goal of the story should be a short statement that is easily understandable by a non-technical stakeholder.
Give clear requirements.
While the goal provides an overarching vision for a user story, it’s obviously not enough for developers to take and run with an implementation. Business requirements can give that deeper clarity.
User stories need to include business requirements to explain how the goal of the story should be obtained. The goal of the story explains why this feature is important and valuable. The requirements explain what needs to happen to get this value.
I choose the term “business requirements” on purpose. These requirements should be stated at a higher level than the technical details. Stakeholders should understand and agree upon these requirements. Ideally, these requirements weren’t written in isolation just for this particular user story. Requirements should derive from documentation written up by the stakeholders with assistance from the developer team.
These requirements help control the scope of the story. They give developer guardrails for what should or should not be done, preventing them from falling into the trap of a growing story. If gaps are identified while working on the story, the requirements help frame conversations for developers and stakeholders. They can then discuss if it’s necessary to address those gaps now or defer the work for a future user story.
Direct with an implementation hypothesis.
Along with requirements, a well-defined user story should also provide an implementation hypothesis. This hypothesis provides relevant technical details on how to deliver these requirements properly. The implementation hypothesis is the best guess on how something should be implemented, taking into account prior experience and best practices for the project.
The implementation hypothesis might look very different from story to story. One story might be straightforward, and the hypothesis should state that. Maybe a story is pretty similar to another piece of work that was done previously. In that case, providing a trailhead to direct developers toward existing patterns in the codebase can serve as a good hypothesis. For complex stories with many unknowns, such as a technical spike of a new library, an implementation hypothesis can point out perceived pitfalls that developers should look out for. It can also call out a time-box that should be given for a task before the developers reach out with findings and clarification on direction.
A well-defined user story brings predictable value.
A well-defined story should provide predictable value to a project. With a concrete goal, clear business requirements, and implementation hypothesis spelling out the technical details, developers can implement features in an environment conducive to short feedback loops. They can easily get started using the technical details from the hypothesis. They can also bump up against edge cases and evaluate what to do based on the requirements and continue to keep an eye out for the goal of the feature and the value it should provide.
Well-defined work is easier to estimate and forecast when value will be delivered. The details in the story support the planning of a project. Teams can understand the complexity of a story with details spelled out in the implementation hypothesis. Developers can control scope creep by staying within the requirements of the story. Well-defined work not only relays information to the developers working on the story but also supports the entire project team in bringing value to the world through the project.