Current Episode

Adam: Welcome to Agile Answers, where every week, I get your questions and you get answers. I’m Adam Weisbart, your Certified Scrum Trainer.

Have you ever struggled with not having enough information when you jump into sprint planning? Maybe the product owner didn’t have conversations they needed to have with the business side of things, or maybe they didn’t have the conversations they needed to have with the Scrum development team. When you get into that meeting, you’re kind of in a loss, and you’re stuck in that time box, how do you get done? How do you make sure you’re in good shape for your sprint? Well, Marcy Damasa had a question about this, really, and we’re going to listen to it here in a moment.

Thankfully, today, for the show, I’ve got a guest. I’ve got my friend Luke Walter who’s another Certified Scrum Trainer who’s going to join me to answer Marcy’s question. Stick around. I bet you’ve had challenges like this in the past. Maybe you’ll pick up some new solutions.

Hey, Luke.

Luke: Hey, Adam.

Adam: What’s going on?

Luke: We have questions. We have many questions.

Adam: Everyone. We’ve got questions to answer for everyone. Okay, for one person, I guess, specifically.

Luke: Just for now.

Adam: Just for now, so we are here to answer Marcy Damasa’s question. And the reason I have Luke on the podcast, other than we just had some tacos together, which were really good, it is that Marcy was in my class and…

Luke: In my class.

Adam: Yeah. So we both know her.

Luke: Yup.

Adam: And we thought it would be cool to answer her question together. So I guess without further ado, let’s listen to Marcy’s question.

“Hi Adam, here’s my question. Often the product owner and business stakeholders need time and input from the development team to help bring their user stories to a state of readiness for work. The team provides information on out of the box capabilities as well as ideas and assistance for creating new features to solve specific business problems and requests. How do you recommend accounting for this work, and where in the Scrum process do you feel it belongs? Thank you.”

Adam: All right, I think there’s a bunch in that question, Luke, but I also think that we can give the very simple answer first, which we could probably tackle easily.

Luke: Yeah, and essentially, Marcy, what you’ve described in the core of your question is a rather nice description of the activity of backlog refinement or backlog grooming.

Adam: Or story time, some people call it story time.

Luke: Story time, it sounds really cute.

Adam: It sounds like there’s dragons involved.

Luke: Dragons and wizards and princesses…

Adam: The official term is backlog refinement.

Luke: Yes.

Adam: Yeah, what you described is backlog refinement. And you can do that in a couple of ways. In original Scrum literature, it wasn’t an official meeting, it was just you spent 5% of your sprint working on the backlog for future sprints.

Luke: Or whatever you find necessary. I think the 5% was a recommendation.

Adam: A rule of thumb.

Luke: A rule of thumb. It was saying roughly this much time might be good to start with. But whatever works for you, whatever you need to be ready for your next sprint with your stories in good shape and sprintable, I like to say.

Adam: Sprintable, yeah. And the other approach that I have seen teams take, and I actually recommend it initially because otherwise people seem to forget to do it, is that you could do a meeting halfway through your sprint. You could call it a ceremony, if you didn’t like the sound of meetings, and you’d spend, I would say, an hour per sprint week, so if you have a two-week sprint, you’d spend two hours or chop that up into a couple of smaller sessions where you get your backlog ready for future sprints. Yup, you do the backlog refinement.

Luke: Or if one big bang meeting is too much or too disruptive, maybe break it up into a couple of different meetings.

Adam: Yeah, so a bunch of these could happen then. And the other time it could happen is any time during the sprint, because business people, the product owner, who’s the proxy for all the business people, and the developer should work together daily throughout the sprint.

Luke: Hey, where’d that come from?

Adam: I think that came from the Agile Manifesto, it’s one of the 12 principles.

Luke: Easy to forget.

Adam: It is [inaudible 00:04:27]

Luke: In the distraction of rules and roles and meetings and artifacts.

Adam: I know. But it’s a good thing.

Luke: Yup.

Adam: So that is the quick answer. There’s places in Scrum to take care of it. Now there’s a couple of things we wanted to parse in your question, and we’re going to make some assumptions here, because we don’t have you to talk to. So if our assumptions are incorrect, we’re guessing maybe they apply to somebody else who might be listening, and so maybe it will help somebody, even if it’s not you, when we make these assumptions.

So the first part is you said where do we account for that work? And usually, when I hear account, it’s a little bit of a red flag. Now I’m reading a lot into this, because we haven’t had the opportunity of chatting about this, but usually, people say account when – well, when do they usually say account?

Luke: When they need numbers.

Adam: They need a number.

Luke: They want to track something.

Adam: They want to look impressive.

Luke: Yeah.

Adam: They want to look impressive. So I would coach my team to not really worry about accounting for it. When I’m planning the sprint, figure out we need to spend some time doing this, and we could think of that, but we could just think of it as a loose concept in our mind. But accounting, I wouldn’t really worry about it. I have my team focus on something useful, like delivering working software.

Luke: Yeah. The thing is that this work is some of the most important work that needs to be done in any software development, or in fact, any product development. What are we looking for? What are our customers asking for?

Adam: Yeah.

Luke: How are we going to turn that into digestible work for the people doing the work? And that is essentially part and parcel with your job as product developers or, if you’re using Scrum, everyone on the Scrum team. The product owner needs to be doing it all the time, probably has to be working with the stakeholders to do it.

Adam: Yeah.

Luke: The development team needs to be giving feedback on that, and it’s an ongoing activity.

Adam: Totally. And this stuff that Luke is pointing towards is all the product ownership, of course, falls to, I don’t know, the product owner, but I see folks worried about definition of ready or you mentioned getting stuff to a state of readiness. I see teams that focus on this. It’s usually because their product owner is not owning the product as they should. They’re not spending all the time they need to with the product backlog. And it’s usually not because they’re lazy. It’s probably because they’re being pulled in many directions by the organization. Maybe they’re a product owner for more than one product.

Luke: Yeah, or maybe they’re too busy is what I often encounter.

Adam: Right.

Luke: They’re too busy to do the hard work, easily half the job of the product owner, which is doing the interpretation and the breakdown of these items with the team.

Adam: Yeah. So if that’s the case, and again we’re making assumptions, and we’re not making any accusations here, but if that’s the case with your team, Marcy, or somebody else who’s listening, then it’s possible that the person you’ve made your product owner or the organization has made the product owner, was put in that position because they’re really important in the organization and they know a bunch, but they don’t’ have enough time, because they’re really important to the organization to actually be the product owner. So those people make fantastic, important stakeholders to actual product owners, people who could spend all of their time, or almost all of their time during their work day being a product owner.

Luke: Yes. And this is the trick for organizations, to make the choice of who is going to be the product owner. Who’s not only equipped in terms of these skills and the requisite knowledge and authority, but who also can actually devote themselves to the hard work of doing this on an ongoing basis?

Adam: Yeah, who’s got the time?

Luke: Yeah.

Adam: Who’s got the time to do this?

Luke: And what we often see or what I’ve commonly encountered is a split where you have, you’ve heard this, the proxy product owner.

Adam: Yeah.

Luke: Which is kind of anti-pattern.

Adam: It is.

Luke: Or maybe not even kind of, but is an anti-pattern depending on who you talk to. I personally feel that it is a dangerous thing to do.

Adam: I vote for anti-pattern.

Luke: Yeah, I vote for it as well.

Adam: So yeah, I would maybe look at that. Maybe the person who’s a product owner is an awesome stakeholder that needs to spend lots of time with the product owner, but it could be a little bit of a trap, I think, to have your team trying to gate things. We can’t accept this into the sprint, because it doesn’t meet our definition of ready.

Luke: It kind of feels a little bit like the stage gates that we get in waterfall, right?

Adam: Yeah, it does.

Luke: Where we have code complete, and working backwards, you might have the SRS and the BRS and other acronyms to represent hand-offs.

Adam: Right.

Luke: That’s essentially what I worry about when I hear of this story-ready is a hand-off between business and development.

Adam: Yeah.

Luke: Which is what we want to break down. We want it to disappear. We want it to be more fluid, a more fluid interaction.

Adam: Yeah, so use a definition of ready if you need to, but only as an interim step that you quickly wean yourself away from. Maybe it helps point to fixing things like getting a product owner to be a fulltime product owner. Again, we’re making assumptions.

Luke: Yeah, hard to know.

Adam: I think we answered her question, though.

Luke: Hopefully we did.

Adam: I feel like that podcast, this episode here is as good if not better than those amazing tacos we just had.

Luke: Put a fork in it.

Adam: They were so good.

I want to thank Marcy for submitting her question. If you’d like to submit a question for a future episode of Agile Answers, visit GetAgileAnswers.com. There on the home page, you can record a message. Maybe we can answer it on an upcoming episode.

Also, if you go to GetAgileAnswers.com/2, that’s forward slash the number 2, you can download the show notes from this episode. It’s got a link to the Scrum Kickoff Planner. It’s a free download of mine. It helps you if you’re starting out a Scrum team or rebooting a Scrum team, lets you consider things like your definition of ready which we talked about in this episode. Super bit thanks to Luke Walter for joining us for the podcast today. It’s great to have him here. And a thank you goes out to Podington Bear who’s responsible for the music for this episode. You’ll find out more about him in the show notes as well.

Until next time, stay agile. Never change.