Can a User Story be too long? Ours seem insane!
We’ll take a look at why teams often use user stories to capture agile requirements and how the format often gets misused. If a user story isn’t a detailed requirement, then what is it?
Mentioned in this episode:
- User Story Mapping by Jeff Patton
Like the podcast? I’d love it if you’d take 60 seconds to rate it in iTunes.
Do you have a question for the show? Submit it at http://GetAgileAnswers.com
Adam: Welcome to Agile Answers. I’m Adam Weisbart, your Certified Scrum Trainer and agile coach. Each week, I get your questions about Scrum and agility, and I answer them, here on Agile Answers.
When working with a Scrum team or any agile team, really, you got to figure out some way to give them some features or requirements. Here’s the stuff we’d like you to build, go ahead and figure out how to build it. Lots of teams use the user story format. It’s pretty popular and actually, my favorite approach for figuring out how you would like to describe a feature. I think it helps you to come up with a great delineation between what is to be built and how you’re going to go about building it. Well, Bill’s got a question to do with user stories today, and instead of spilling the beans, let’s listen to his question and I will see if I can help.
Bill: Hey, Adam. This is Bill. My organization provides requirements to my team in the user story format. While following the normal template for the user story, they’re really long, and have tons and tons of acceptance criteria are attached. My question is this, is it possible for a user story to be too long? Thanks for your help. I love the podcasts.
Adam: Hey Bill, thanks for submitting the question, and thanks for loving the podcast. That’s awesome.
All right, so can a user story be too long? Most certainly, it’s totally possible for a user story to be too long. How long is too long for a user story? Well, instead of just directly answering that, I would like to go and take a look at why we have user stories to begin with.
As I mentioned in the intro, they’re a fantastic way of defining features. They’re called user stories, of course, because they’re from the perspective of the user. They’re the features the user would want, not the implementation as to how we are going to go about achieving that for the user. This way, a non-technical person like a non-technical product owner could figure out tons of features without knowing any of the underlying technology, because after all, your users probably don’t care what database you’re using, what frontend framework you’re using, or anything like that. They care about the value they get out of the features you’re providing them.
If you have a Scrum team of cross-functional experts or highly proficient people, there’s also no reason to hand them an exact spec as to how they’re going to go about accomplishing this task, or rather building this feature. So user stories are great at focusing your mind on the feature level and getting away from implementation.
Unfortunately, they often get misused. And the way that I see them getting misused is that they describe in great detail exactly how the feature is supposed to work. And that was never really their intention, right? Their intention is to define what is to be built, and to let the team of development experts including UI and UX folks and database folks and server side folks, everyone you need to get the feature done, allowing them to figure out how they’re going to solve this problem. And if you hand a team perfect spec as to what they’re going to build, there’s actually no reason to have a high performing, cross-functional team. All the work’s already been done – a bunch of the design work, a bunch of the UX flows, that’s work’s already been done, and you’re just handing them off to the team, and saying, “Hey, follow these really detailed user storied that are really long with tons and tons of acceptance criteria, build me that thing, and then I’ll be happy.”
Well, it turns out, you probably won’t be very happy, because it’s pretty hard to define everything perfectly upfront. In fact, that’s the whole reason we do this crazy Scrum thing or why we follow agile principles. We do it all because you can’t plan everything up front, but you can get a good idea of where you’re going. You can get a good idea of the features you would like, and you can trust your team to go ahead and build those things and you can review their progress at some regular interval.
So back to your question. I suspect that if you have tons and tons of acceptance criteria, and your user story’s really, really long, that one of a couple things is happening. The first is the user story you had was probably not bad, if you weren’t going to work on that item for six months or so, but probably pretty crummy to pull into an actual sprint. It probably has not been refined enough. So I would make sure that my team had backlog refinement every sprint, so that they could clarify what these big items meant and break them down into smaller and smaller items.
I like writing my user stories for a sprint onto index cards. If you can’t fit your user story and all the acceptance criteria on the back of that card, then I suspect it’s probably too big. So I like the 3-inch by 5-inch constraints you get on an index card.
Jeff Patton, who wrote a great book called “Story Mapping,” he’s got a whole book on story mapping which I highly recommend checking out. I’ll leave a link to it on the show notes. I really like his work with user stories. There’s this idea that epics are user stories that are too big to fit into a sprint. He actually hates the terms “epics” but nevertheless, user stories that are too big to fit into a sprint, and I suspect what you have is a user story that is too big to fit into a sprint, and I suspect that’s because someone upfront is trying to do all this design work and give it to the team just like they would a spec if we were doing a waterfall approach. User stories were never meant to be a spec. They were meant to start a conversation.
And the reason I bring up Jeff Patton, other than his awesome book which doesn’t directly relate to what we’re talking about, is that he’s got this saying or this little story he tells that user stories are a lot like a phot from your family vacation. If you will set your mind back to one of your favorite photos from a family vacation, for me, for example, it’s going to Hawaii and sitting on the beach, and the photos of us hanging out there on the beach, in the sun. If I think back on it, I can smell the suntan lotion and the air in Hawaii, and I can feel the warm breeze blowing on me, and I can hear the lapping of the ocean. If I show that photo to somebody, I suspect their reaction will be, “Yeah, it’s a nice photo.” They don’t get all the context that I got from being there. They don’t get all the smells and sounds and conversations we were having on the beach and all of that. For me, that photo is a pointer to the experience that I had with my family. And Jeff goes on to say that that’s just what the user story is.
The user story was never meant to have so much information that you could hand it to a team and then never talk to them again until the end of the sprint, because you just won’t get the thing you were thinking you wanted. It doesn’t have enough room, nor should it. It should just be a pointer to the conversation you had. So the acceptance criteria should be pretty brief, because you have small user stories that you pull into your sprint. The user story should be pretty brief as well, it’s just three lines. Even a long one can fit on the front of an index card.
The goal here is to get the team and the product owner on the same page about their conversation, not to capture every single thing so the team doesn’t go wrong. The team is not going to go wrong because they’re going to have conversations with the product owner throughout the sprint and they’re going to use this index card or their user story to drive that conversation, to write down small specifics that they’ve agreed on as acceptance criteria, and they’re not going to use it as a full spec. it was never meant to be a full spec, and there’s no reason you should force it into being a full spec. you should really just have your product owner and team talk throughout the sprint. After all, business people and developers should be during that through an iteration anyway. I think it’s one of the twelve agile principles after all.
Bill, I hope that was useful. It is possible for a user story to be too long and too have too much acceptance criteria. The first thing you should do of course, is make sure your product owner has enough time to be a good product owner and to refine these things with the team. If you’re doing Scrum, I recommend spending 5% to 10% of your sprint doing backlog refinement. You could do that ad hoc or as one meeting halfway through your sprint, getting your product backlog ready for future sprints. It would let you discuss these large user stories so that you’re in better shape when you got to your sprint, because heck, they’d be small user stories then.
For having your question featured on Agile Answers, you’ll get a deck of my Agile Antipattern Cards. In fact, I think one of the Antipatterns is having a user story that’s giant and thinking there’s no possible way to make it smaller. There’s always a way to make it smaller. Story splitting, it’s a fun hobby and/or career goal to get good at. So story splitting, awesome. Sounds like your story needs to be split up some.
If you’ve got a question that you would like featured on Agile Answers, you can go to GetAgileAnswers.com. Right there on the home page, there is a widget where you can record your voice just like Bill did, asking his question, so that I can answer it, maybe, on a future show. If it gets answered, you’ll get a deck of my Agile Antipattern Cards as well. If you’d prefer to submit a question by email, you can do that there as well too, and I’ll read it on the show. You don’t have to use your voice, if you don’t want. It’s up to you.
I will give a link to Jeff Patton, his book and his website, if I can find the most recent one. Jeff Patton is a great resource for all things product owner-ish. I love his work, so we will link to that as well. You can get in touch with me on Twitter @weisbart.com, that’s @-W-E-I-S-B-A-R-T, and I’ll see you there. That’ll be fantastic.
Until next time, stay agile. Never change.
What agile practices can you recommend to our game development studio?
How do we remove silos when doing government contract work using Scrum?
How should we form new Scrum teams?
How can we have good retrospectives (about our Scrum Master)?
When’s the podcast coming back?
How do we self-organize if our boss is on our team?
How do we deal with constant interruptions to our Sprint?
Can our Scrum Master and Product Owner be the same person?
What 1 simple thing can I do to improve my coaching & scrum mastering?
How do I get hired as a ScrumMaster if I’ve never been one before?
Our team wants to be more agile. What agile process is best?
How do we improve our giant, multi-team Sprint Review session (or Sprint Reviews in general)?
What are some creative & effective ways to make Retrospectives more engaging?
Will this hurt my Daily Scrum? And how do we deal with “non-dev” work?
How do I escaped the dreaded ‘Scrummerfall’ trap?
How do you help PMs and Managers not fall back into their waterfall ways?
Our teams keep changing. How do I set guidelines that keep teams together?
How do you make sure your team has time to make the improvements they identify in their Retros?
When should the business stakeholders get help from the dev team to get items ready for work?
How do I energize a demotivated Scrum team?
Mic Check! 1…2…3…