User Stories

User stories are a ticket type in work management systems that I admit I have abused regularly. If I could calculate a percentage of actual user stories versus all the “stories” I’ve written, I would not be shocked if it was less than 10%. This is likely due to me jumping ahead mentally to the tasking part. If I understand what is being asked and I have the skills to do it, then my sprint can consist of actionable items that contribute to the goal.

In the book “Essential Scrum” by Kenneth Rubin, user stories are defined like this:

“User stories are a convenient format for expressing the desired business value for many types of product backlog items, especially features. User stories are crafted in a way that make them understandable to both business people and technical people. They are structurally simple and provide a great placeholder for a conversation. Additionally, they can be written at various levels of granularity and are easy to progressively refine.”

However, much to my surprise actually, the author doesn’t presume that user stories are the only way. He goes on to say, “If I find that user stories are a forced fit for a particular situation (such as representing certain defects), I’ll use another approach.” I’m glad to learn this because I’m in the very situation right now. Part of the current project I’m overseeing includes merging two applications into one user experience. Some of the changes are going to be back-end changes that provide the existing user experience with a new API. Having a story like, “As a user I want some button to work like it always has with a new API endpoint” kind of works but also seems a little silly.

One of the challenges I have with managing sprint work is having front-end and back-end engineers. When you use a user story, there usually isn’t a distinction between front-end work and back-end work. But for some tickets, the front-end work might be light and the back-end might be heavy. The systems I’ve worked with only allow one person to be assigned the user story. When you point it, do you point the front-end and the back-end and take the highest number? Add the story points together? If you don’t split the front-end user stories from the back-end user stories, how can you know your true capacity? If I have two back-end developers and two front-end developers and the highest value work happens to be back-end heavy, do I just have idle front-end developers? I’ve also had teams complain that the front-end can’t really finish their work until the back-end dev is done. Some of us suggested having the back-end done first in one sprint and then have the front-end work done in the next sprint (requiring split tickets), but that was shot down. When I run into situations like that, I feel like agile zealotry get in the way more than helps.

Regarding the front-end development versus back-end development, there is such as thing as a “full stack” developer, but don’t kid yourself. I’ve interviewed dozens of full stack developers. They are always stronger with some disciplines and weaker on others. Giving one dev both front-end and back-end works nicely from a ticket perspective, but there’s a natural fault line where two developers could work at the same time without stepping on each other that can be lost.

Stay tuned for more exciting adventures as I push through this reading. Cheers!