Avoid Technical Stories
Many Product Owners don’t have a lot of experience writing requirements, and if you’re a BA like I am coming from a waterfall world, you tend to like to write a lot because that’s what you used to have to do. But now user stories are meant to be from the user or the business perspective.
I’ve seen some teams that tend to write stories from a technical perspective, and I would caution against that. I am not a fan of a “technical story”. Unless a story has value that is delivered, and that is measurable and usable by the end user customer, then you’re not delivering anything of value. Avoid those types of stories. Always try to look through the lens of your customer or your user.
Slicing the Cake
Another thing many organizations struggle with is slicing the cake (see right). In the old days of software development, you’d have to do these horizontal layers one at a time until they were all done, and you wouldn’t get any value delivered until the very end.
In agile, you’re going to take a thin vertical slice of just what you need to do that action –such as pay with PayPal –and you’re going to go through all the horizontal layers to get something that completely works. It just does that one very narrow function, but you have everything you need to get value out of that right away.
Don’t Forget to Include the “Why”
If you’ve ever heard the user story format, “(as a [role], I want [something], so that [I can get some benefit])”, the why is the “so that” part of the story. Many people tend to get lazy and forget to do the last part because it’s not convenient. They actually have to think about why. But I caution against not including that. You really need to have the “why” for the development team. It gives them the context that helps them understand what value is provided by doing the story. Without that, they’re not going to know why they’re doing it, and they’re probably going to ask you anyway. You might as well put it in there.
Write Stories at Just the Right Size
Finally, writing stories at the right size is also very difficult. Think about Goldilocks and her experience with the “just right” porridge. In this case, you want to have stories that can be completed within a Sprint, and it’s great if you can right-size your stories so they’re all comparably sized. It’s not always possible, but you also don’t want to have stories that are too big. Those are epics.
Epics are stories that would need to be decomposed into smaller stories to be delivered within a Sprint. An epic could never fully be delivered within a Sprint. On the flip side, you could also have stories that are too granular. In that case, you might want to consider combining some to make it a larger story.
