294. User Stories: Why "gathering requirements" is not a gorram story (Replay)

As much as we hate breaking bad news to you, we have no choice today. If you think gathering requirements is a user story, you are wrong and we’ll tell you why. William, who is especially fired up about the topic, gets us started by explaining that usually gathering requirements is conflated with other components, such as a spike, task or research and there are also often delusions about what stories are. While it is important to keep track of all the tasks on a project, they should not be confused with user stories.

Gathering requirements is simply part of the job of being a developer and while there is a need to record tasks, if they get put on the PO board, it can create clutter and drown out the real user stories. So instead, it is important to label activities for what they are, be it a spike or task. This ensures that user stories shine on the board and they get the attention that they deserve. There are some task management tools we talk about that can help with sorting different project tasks to ensure that you never mix up gathering requirements with user stories again! To learn more, join us today.

 

Key Points From This Episode:

 

  • User information gathering techniques: focus groups, implicit feedback and an embedded customer on the team.
  • How to quantify time that is dedicated to interacting with the customer.
  • Uncertainty is natural and sometimes options need to be tested.
  • Just because it’s on the PO board, does not make it a story.
  • To-do list mindset: why people often put gathering requirements as stories.
  • Preliminary research does not belong on the PO board.
  • If a user can’t brag about or share a feature, it’s not a user story.
  • Each user story should have lots of tasks on the task board.
  • Not all project management software differentiates stories from tasks.
  • Some useful task management websites and tools.
  • An ‘icebox’: storing half-formed ideas that could potentially become future stories.
  • It is important to get user feedback before you create a development roadmap.
  • How many stories it is good to have stored for future deployment.

Transcript for Episode 294. User Stories: Why "gathering requirements" is not a gorram story (Replay)

[INTRODUCTION]

[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea, Manhattan. I’m your host, Michael Nunez. Our co-host today.

[0:00:09.8] DA: Dave Anderson.

[0:00:10.8] MN: Our producer.

[0:00:12.0] WJ: William Jeffries.

[0:00:12.8] MN: Today, we’re going to talk about user stories and why gathering requirements is not a damn story. Language man.

[0:00:22.7] WJ: He’s right though, it’s really not.

[0:00:24.1] MN: Hey, so William came in today and it was just hot, really spicy talking about this one topic and we’re like hey, let’s talk about this, maybe our listeners will be interested in your spicy hot take and why this is a thing that we do not want to happen. Go ahead, tell us the story.

[0:00:42.4] DA: So you brought the Siracha?

[0:00:44.3] MN: Yeah.

[0:00:45.2] WJ: Yeah baby.

[0:00:46.3] MN: Spicy, go ahead.

[0:00:48.0] WJ: That ghost pepper.

[0:00:50.5] DA: I don’t want that. Keep it.

[0:00:52.6] WJ: Well, so a friend of mine texted me and he was like “Hey, my team wants to play a user story that is gathering requirements,” is that a user story?

[0:01:03.1] DA: Well, as a user, I want the requirements so I can have the requirements. That’s why –

[0:01:13.2] WJ: Oh My god.

[0:01:13.9] MN: That’s what [Kent Beck] would want, right? Yeah.

[0:01:17.3] WJ: This is yeah, I mean, this is exactly the problem, you’re delivering no user value when you gather requirements. That is just you being lazy about writing the story with real requirements. You just didn’t gather requirements for the story.

[0:01:31.1] MN: Well what if that’s the story for this particular person? Often times, you’re on a JIRA board and usually, the project manager isn’t on the board like delivering user value but what if the user value and the project manager story is to get the user’s story to make stories for engineers to deliver value for the users?

[0:01:54.3] DA: What?

[0:01:55.8] MN: Isn’t the project manager collecting user requirements helpful for the user because then they’ll get those features eventually, I guess is my question.

[0:02:05.1] WJ: Yeah, explain to my mom who is using her Netflix account like why it’s valuable to her as a user for like some product manager at Netflix to gather requirements for a story.

[0:02:18.9] MN: But isn’t that like so, what would you count that work like say, so let’s talk about collecting information from the user, how some ways you’ve seen information collected?

[0:02:29.7] WJ: I mean, you could do focus groups, you can have customer embedded on your team, that would be the most XP way of doing it but you can get –

[0:02:37.1] DA: That’s a good question —

[0:02:38.0] WJ: You could get implicit feedback by running tests and you know, checking to see whether users engage in a particular feature or button or on around the page.

[0:02:47.1] MN: So if I have a customer coming in who is going to use my product, and I’m going to block a window of time and that person comes in for two hours and uses the product and gives feedback, how would you measure that work or the project manager, is that just like in the ether?

[0:03:06.4] WJ: That’s just their job, that’s what they do.

[0:03:11.2] MN: So they’re just then on the board —

[0:03:11.6] WJ: Why are you messing up my JIRA board, that’s just your job, you just go to that.

[0:03:16.1] MN: Go get the requirement, do the survey.

[0:03:18.0] WJ: You talk to users, that’s your job, that’s why you’re the project manager.

[0:03:22.2] DA: It’s like the equivalent of a dog ate my homework kind of thing. Like — I don’t have a story because I didn’t do my homework really but here’s my story.

[0:03:31.5] WJ: Exactly.

[0:03:32.8] DA: How do you deal with uncertainty though? Because like, sometimes you do have to work through on certainty to figure out what the best option is, maybe you have like three options.

[0:03:45.8] WJ: Yeah, I mean I think it’s perfectly reasonable to say I’m going to play a spike,  you know, we’re going to do a spike ticket and we’re going to do some research and there’s not going to be any new functionality and that’s just not a user story, that’s just not. It’s a task, it’s a developer task, it’s the thing that gets done and it’s the thing that could be on your board but it’s not a user story.

[0:04:05.1] MN: Right. So it could still be on the board?

[0:04:06.9] WJ: Yeah, like it can still be on the board but like gathering requirements, come one. Get that out of here, get that garbage out of here.

[0:04:13.1] MN: Spicy, William is spicy right now.

[0:04:17.4] WJ: I mean, that would be like putting like going to stand up on the board, no. Okay, go and show up to stand up. You don’t get credit for that, we’re not dragging that through QA.

[0:04:26.3] MN: That’s too poor.

[0:04:27.8] WJ: Nobody is QA’ing that you went to stand up.

[0:04:30.2] MN: I estimate going to stand up as three points.

[0:04:32.8] DA: I feel like what you’re running against is like the delusion of the HL brand where it’s like okay, someone told me I need to write a story. Sp the thing that I write is going to be a story. I’m just going to label it as a story and then like, forget about what the true definition of what a user story is.

[0:04:51.7] WJ: Yeah, I mean it’s like people are used to like to do lists and other kinds of productivity management tools and then they get on to a Trello board or a club house boarder or a JIRA board, whatever. They approach it with that same mentality where it’s like, if this is work that I have to do then I should write it down and put it in this piece of software because that’s where work goes.

[0:05:13.5] MN: Yeah if it’s not there, then what are you doing?

[0:05:16.5] WJ: Right, you’re justifying your own existence with tickets.

[0:05:18.9] DA: I do worry about that sometimes about like if there’s a lot of things on flight like I might lose track of something or like forget to capture an edge case or something like that.

[0:05:31.2] WJ: Yeah, I mean, it’s important to track those things, it’s just like they’re not user stories, right?

[0:05:37.7] MN: As a user.

[0:05:38.4] WJ: I’m not saying don’t write stuff down. I mean, yeah, absolutely, I mean, if you are a product manager or a product owner and you know, you have tasks that need to get done like you need to do some research on a particular topic, you need to run some analytics to see how a new feature is doing, whatever. All of that, you should definitely track that somewhere or just that you know, that may even inform user stories that do get played later.

It’s just that that kind of preliminary research doesn’t belong on a JIRA board and putting it there is just going to mess up your stats. Because you know, at some point, you’re probably going to want to start tracking your cycle time, you’re going to want to start looking for bottle necks. Where in your process are things getting stuck? Where are you getting a lot of work in process piling up.

If you have stuff that doesn’t deliver user values, sort of cluttering things up, then that’s going to throw off your metrics.

[0:06:38.9] MN: Right, especially when that particular user story could potentially have points that aren’t real I’m going to say I guess?

[0:06:47.0] DA: Oh my god, are you pointing this too? How many points was this story?

[0:06:51.1] MN: How many  points is that story, yeah…

[0:06:52.6] DA: I didn’t even think about that.

[0:06:55.4] WJ: 13 point requirements gathering ticket.

[0:06:57.1] MN: That burned down chart bro. Go straight down like it’s just a cliff. Just goes straight down. If it’s pointed.That’s the question that I would ask why is this pointed and –

[0:07:09.6] WJ: I should ask my buddy who is in this situation whether they pointed, I think they did, I think they had an estimation meeting and they were story points on gathering user requirements —

[0:07:18.1] DA: That’s a doozy, that’s a big one, lots of complexity in that.

[0:07:21.5] MN: 100.

[0:07:22.1] WJ: There might be, maybe you’re like negotiating a new contract with like a massive customer and they have all these custom requirements and you have to go and figure out where they are and spec out what you’re going to build and hopefully not commit to a crazy deadline to deliver it all by but you know, there could be meaningful amount of work there. It’s just that if you can’t phrase it from the perspective of a user, if it’s not a thing a user actually cares about, it’s not a user story.

[0:07:45.9] DA: Right, the base definition of like a story is something that a user would tell someone about excitedly like, “Oh, this thing does this thing from a – “ if you can’t like, you know, brag about it or like, you know, excitedly share it with somebody then maybe it’s not like a story.

[0:08:08.1] WJ: Right, it’s like you know, as a customer, I would like to adjust the quantity of a particular item in my shopping cart so that I can buy a different number of that item without having to –

[0:08:23.5] MN: Go to the main page.

[0:08:24.7] WJ: Yeah, restart my shopping experience.

[0:08:26.4] MN: Right.

[0:08:27.7] WJ: Whatever. It’s a thing that adds value for the user and I think you know, a common problem that you see is, boards start to get cluttered with tasks because tasks are also a thing that need to be dragged.

[0:08:39.4] MN: Right.

[0:08:40.1] WJ: And then if it becomes difficult to see how much user value you're actually delivering because you know, you have all these things that are not user value related on your board and you might even see like wow, things are really moving. You know, you got a lot of cards moving let to right across the board but from the user’s perspective, nothing is happening.

[0:08:57.7] DA: I want that rush of moving the cards though. You got to move a card, William.

[0:09:01.2] WJ: Yeah, well then task boards are the way to go, I mean, this is what Kent Beck talks about and user stories apply, it’s like you have a task board in every user story should have lots of tasks. Developers can come up with whatever task, you say you want and you can run them across the board to show progress and it’s actually much more insightful for someone who wants to check on the board and see how that task is doing because they can see all the little pieces.

[0:09:25.0] MN: Right.

[0:09:25.5] DA: Right. It can be kind of frustrating though when your tool that you’re using just calls everything a story like the entity that you’re creating is a story. Even if you’re making a spike or if you're making a task.

[0:09:43.3] WJ: Yeah, some tools don’t really support this. This is a major complaint that I have about Club House is that Club House does not support the concept of a task board.

[0:09:50.7] MN: Everything is a story —

[0:09:52.3] WJ: Everything is a story — they have a separate concept of tasks. For them, tasks are things that can be checked off inside of a story but they can’t have states.

[0:10:01.3] MN: Right.

[0:10:02.5] WJ: And that’s frustrating if like you have little individual pieces that you want to be able to ship daily.

[0:10:08.2] DA: They do have the ability to separate like user facing value as like tagging as a feature versus like other forms of nonuser facing value like chores or bugs.

[0:10:21.9] WJ: But then you can’t associate those with anything except maybe an new pick.

[0:10:24.9] DA: Right. Yup, it’s very opinionated — opinionated about things.

[0:10:30.8] WJ: Right, it’s mostly good opinions,  I have mostly good things to say about Club House but this is one major complaint that I have to say. They have no support for task boards.

[0:10:40.6] MN: So as project managers, that all those changes would exist in the task board like “Hey, you know, interview Bobby at two and Suzie at three,” and the pull information form them and then use that information to generate the user stories that may have been revealed during those I’d say, surveys or interview questions. Then those things become story. Stories rather. Or like as you mentioned, “Hey, my job for the day is to create user stories,” like it’s not a user story because it’s what I need to do for the day and that’s not a user story, that’s a task.

[0:11:18.7] WJ: Right, it’s okay to have other task management software besides your JIRA board. You’re going to have a to do list, you can have wonder list or “toodledoo” or whatever — pick your poison there, a million task management tools out there. I just use a text file that I edit in VIM with a to do and doing and a done section a lot of the times.

[0:11:41.0] MN: Nice. Would you suggest like Trello as well as one of those things.

[0:11:45.4] WJ: Yeah, Trello could be cool, I mean yeah, if you want to have something on the side just for yourself, you can setup your own board. I mean, Asana, I use OmniFocus for like really heavy duty task management stuff although that’s really pretty steep learning curve so –

[0:12:00.2] MN: What about the concept of like an ice box. Just like having a pile of like things that are like half formed that you know, you’ll work on and maybe they’ll become user stories and maybe they’ll just get thrown away or maybe they’ll just sit there forever.

[0:12:18.1] WJ: I think that it’s really better not to put that in your story tracking software, you kind of want to put that in a separate place like UserVoice is much better suited to that particular job. If it’s a thing that you haven’t decided whether or not to do, you want tooling that’s going to help you decide whether or not to do it. Not tooling that’s going to push you into doing it whether it’s a good idea or not.

[0:12:39.8] DA: What is UserVoice?

[0:12:40.3] WJ: UserVoice is a cool tool that has like a lot of features for not just gathering feedback from users about potential features but also sort of like road mapping out what you’re going to build and making sure that it’s things that users actually care about. You know, they have like up vote, down vote features or like an up vote down vote functionality for a given feature. Users can request features directly.

You can sort of use that to organize your thoughts before you start road mapping as a product portion.

[0:13:10.8] DA: Yeah, I think I’ve seen something similar with like Spotify’s bug board. They have forum and kind of like engage with the support people and people request features and brigade for them.

[0:13:25.4] WJ: Yeah.

[0:13:26.5] DA: It can be sad though because you know, I really want this feature and there’s only like 12 people who will care about it it’s like, “Boy, that’s it? I thought it was so important, it’s so important to me.”

[0:13:36.9] MN: Such a good feature.

[0:13:37.9] WJ: Although, that’s a really nice way of sort of servicing to your users in a kind way. Why you’re not going to do the thing that they want you to do. It’s like you and you know, six other people and here’s these other feature that’s got 7,000 votes and it’s like, I mean look, we care about you as we usually want to get to that eventually but there are priorities, there’s a timeline.

[0:13:57.6] DA: I don’t’ know.

[0:13:59.0] MN: I want that feature now.

[0:14:00.6] DA: Yeah.

[0:14:01.3] WJ: Do my thing.

[0:14:04.0] DA: They eventually got to it, I forgot I wanted it at some point, shut up on it.

[0:14:09.6] WJ: Five years ago, I requested that Source Tree have adjustable font sizes and I still get emails every month from other users requesting that same feature and they just have never done it, they’re never going to do it. It’s going to be there forever.

[0:14:26.7] DA: Yeah, okay. Is that the ice box?

[0:14:29.8] WJ: But the problem is I mean, if you put that in your own back log, it ends up drowning out all of the actually important work. It gets mixed in with the things that actually are important and you know, sometimes those stories even accidentally get played because people forget like we actually didn’t really vet this that thoroughly to make sure that it’s actually going to deliver all about you.

[0:14:49.8] DA: Right. Isn’t that the dream though? Someone accidentally add the feature that you want? Yeah, that’s beside the point, yes.

[0:14:59.8] MN: Okay. This makes sense. We have to ensure that the project manager or the product owner is not writing stories to collect user stories but to get user stories on the board and the faster, that individual can do it, the faster we can deliver our stories to our users.

[0:15:19.7] WJ: I think ideally you want like maybe three sprint’s worth of stories in your back log? You know? The current sprint should be really fine grained, well defined, next print should be sort of medium grained, definition and then you know, two sprints out should be sort of rougher and then everything else should be captured in a road map and you shouldn’t have bothered wasting time, fleshing out stories because you just never have less information that you have right now.

[0:15:46.2] DA: The old cone of certainty.

[0:15:47.5] WJ: Yeah. The cone of certainty. Flushing those stories out now, I mean, it’s just a waste of time and it can come back to bite you if you trust in those stories just because somebody wrote them.

[0:15:58.3] DA: Right, and then the assumptions that were made at that time like, you may lose context about what assumptions you made and what you’re going to check and what was important to you at that point is different than what’s important to you now?

[0:16:13.9] MN: Yeah, Will, you are really spicy about this topic so let’s make sure that our listeners will help their product owners and project managers to not write collecting user requirements as a user story. Let’s just make sure we do that to ensure your blood pressure doesn’t go too high or anything of that nature.

[0:16:32.8] WJ: I mean, I think I would caution compassion for your product people but also to encourage them to make use of other tools aside from JIRA or Club Houses or Trello or whatever you happen to be using.

[0:16:45.4] DA: Right, or, just label it for what it is. It’s a spike, it’s research or you know, if it is like user research like that’s even maybe before a spike because spike implies some kind of technical research and some kind of like technical learning and outcome that’s going to be there but yeah, spike’s a good alternative to a making a story for the story. The outcome may be a story from a spike or –

[0:17:12.8] WJ: Yeah, I think that’s a good outcome for a story. A story should have a time box and it should have an outcome and one sensible outcome is that there are well defined stories that you can play. But just don’t call that a user story and take credit for it.

[0:17:25.4] MN: I put points on it.

[0:17:28.0] WJ: Man, our velocity is so high, we like wrote all of these stories. Like 30 story points worth of us just sitting around writing more stories.

[0:17:37.3] MN: Oh yeah.

[0:17:40.1] DA: Motion machine, yeah.

[0:17:42.6] MN: Don’t game the system ladies and gentlemen.

[END OF DISCUSSION]

[0:17:45.0] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.

[END]

 

Links and Resources:

The Rabbit Hole on Twitter

Trello

User Stories Applied

Kent Beck

Clubhouse

Todoist

Toodledo

Wunderlist

Asana

OmniFocus

UserVoice