I have spent much of 2021 working as a product owner. I receive new insight each day into the role. I have developed empathy for the people who do the job and the unique pressures they face working on a large-scale project. I have noticed in my tenure that writing user stories does not appear to be a consistent skill among my peers. From time to time, when I point out ways to make stories better for the development team, I get testy pushback from my peers. This time on the blog, I want to cover story writing and the INVEST model.
Readers of this blog will appreciate that I am a fan of Roman Pichler and his D.E.E.P model, and I have written a few blog posts about the subject over the years. Lately, I am noticing that some product owners are struggling with the basics of authoring user stories. I spend plenty of time sharing my blog posts on how to write better stories with my colleagues.
Lately, some of my peers have asked what makes a good user story, and I did not have a good answer until I learned about the INVEST model. First proposed by Bill Wake in 2003, the INVEST model has become the gold standard for user stories. Once I understood its purpose, I became an enthusiastic advocate of its application in story writing. INVEST is an acronym that stands for; independent, negotiable, valuable, estimable, small, and testable. Following this model will make your stories better, require less work for the development team, and make like easier for the product owner.
Independent, when we say a story is independent, it can be worked on individually and not rely on someone outside of the team for completion. The development team can work on separate user stories in any order. Finally, if a story does rely on dependencies, it can be easily mitigated with mock data. User stories should not create constraints or bottlenecks in the overall project.
A negotiated user story is not a contract or recipe to follow slavishly; instead, it is a conversation. The product owner and the development team should give and take to know what to build but not how to do it. In my experience, the most significant area of conflict is when a front-end developer and a UX designer clash over the implementation of a design. The UX designer often wants the developer to match the graphics file pixel per pixel. The realities of CSS, HTML, and JavaScript can make that like jamming a square peg into a round hole, so it will require negotiation to get everyone to agree on how the page will look and behave.
When a story is valuable, it means that its completion will add value to the customer or the project. The development team or product owner should scrap any user story we cannot explain how it helps a customer or drives revenue for the project. It is hard to do in hierarchical organizations because the highest-paid person in the room often makes project demands to have work done that delivers no value but satiates their ego. When in doubt, provide value to the business and customers, the executives will have to pay for their ego gratification with their own money.
Each story in the backlog should have an estimate. The team should take time and ask how complexity, risk, effort, or uncertainty surround a story. It then allows the team to make an educated guess about how long it will take to complete the work. An estimate is not a quote for work because it may be off. Still, if the team cannot estimate a story, the product owner will need to refine the story further to allow the development team to provide an intelligent estimate.
Small stories require less time to complete, and these types of stories are easier to understand and provide a swifter path to success. I talk about the importance of smaller stories here.
Finally, a user story must be testable. Suppose you cannot quickly test a user story with either a unit test or easy-to-understand instructions. In that case, the story is overly complex, and it will generate further delays to the project because no one understands what the story is supposed to accomplish. Keep things simple, and to keep them simple, they should be testable.
That is the INVEST model. A user story should be independent, negotiable, valuable, estimable, small, and testable. Following this rubric will make writing user stories easier and will help get work done more efficiently.
Until next time.
No comments:
Post a Comment