User stories are one of the places where you as a Product Manager get the chance to sell and align the Engineers with your view. Failing to write good stories can result in developers going in circles, focusing on the wrong problem, or ending up building something other than you intended. That is neither good for the velocity, nor the relationship with your engineer as you will have them throw away code they have already spent significant time on.
To cope with this, there are multiple frameworks and guides to help Product Managers write great stories. One of the most popular frameworks that I have found very helpful is ‘INVEST’ which stands for:
- Independent
- Negotiable
- Valuable
- Estimable
- Small
- Testable
Independent
One of the core fundamentals of agile is that stories should be able to be worked on in any order as prioritization seems fit. By making stories independent, you will enable true prioritization. However, there are times when there are dependencies, especially when working on tech-debt, or refactoring projects where the order needs to be taken into account. When possible, consider making the stories as tasks or subtasks if they are so closely related to each other.
Negotiable
A story should not tell you how to do something, but rather what the desired outcome is. By nature, there should be a negotiation between engineering and product on how this is best achieved.
Valuable
The value of a story should be the driving part — what value are we getting by doing this? It should be tightly correlated to the KPIs and Metrics your team is working towards in that period and sprint. If it doesn’t, there is something wrong with the prioritization. But remember that internal values are also important and that everything you build does not have direct end-user value. Especially if you are working on internal products or platforms.
Estimable
If you can’t estimate how much work a story will be, it should be very difficult to complete sprint planning as the engineers can’t tell how much work they are able to commit to. If you are running into this problem, it usually helps to break the story down into smaller pieces. If this is still difficult to do, you probably need a time-boxed spike to get more clarity into the task so that it can get estimated.
Small
Stories must be small enough so that they don’t take up a full, or the majority of a sprint. If that is the case, then it should probably have been an Epic that needs to be broken down into smaller stories. If the story is too big, it most likely is also hard to estimate and test so you should see red flags if your story is getting too big.
Testable
One of the most important pieces of information in a story is the ability to test it to ensure it meets requirements. It will also help the developer to know when they are done. Usually writing acceptance criteria is a great way to start writing a story and making your way backward. Making it testable will not only get you brownie points from QA but make your engineers much happier too. If you are struggling to write tests, you might find this post I wrote helpful: Perfecting acceptance tests for your user stories
Using a framework like INVEST to write great stories will make every part of the agile process easier as grooming and planning will be much more clear. If everything goes well it should also enable the engineers to be more efficient, and your team will ship products faster. In its turn, this usually makes the team happier and makes everyone a winner. INVEST in great stories, and you will find that your life as a PM becomes much easier and more fun.
/Svensson
