How To Plan An Agile Sprint (With Alexa Huston From Crema)

Ben Aston: Welcome to the DPM Podcast, where we go beyond theory to give expert PM advice for creating better digital projects. Thanks for tuning in. I’m Ben Aston, founder of The Digital Project Manager.

Be honest. Do you leave your sprint planning meetings with a well-defined, agreed-upon backlog complete with well-defined estimated items in full confidence that your upcoming sprint is going to go exactly to plan? Thought not.

While we all know sprint planning is a good idea and critical to the success of the project, it’s hard. It’s hard to get it right because we’re trying to reduce ambiguity and we’re trying to get alignment with our team and we’re trying to get to some kind of agreement. That is always tricky.

How can you start your sprints off right and do the planning that’s actually needed to get your sprint moving in the right direction, and not just another false start that requires another planning meeting? As PMs, it’s our job to get this done right. But how do we do it? Planning an agile properly is what today’s podcast is all about, so keep listening to find out how you can get your sprint started right.

My special guest today on the show is Alexa Huston from Crema. Alexa is a former DPM, and now she works in new business. This challenge that we have is something that she’s well acquainted with. Alexa is one of our resident PM experts in the Digital Project Manager School. If you want to learn more from her, check out our Master of Digital Project Management School where she’ll be making an appearance. Go to DPMSchool.com to find out more about that. Hi, Alexa.

Alexa Huston: Hi, Ben.

Ben Aston: Welcome to 2019, our first chat of 2019. What are the big goals for 2019 for you, Alexa?

Alexa Huston: That is a loaded question. I actually did that hone on New Year’s Eve and wrote down some things. I’m not a huge resolution person, because I think I’m constantly setting goals. But I want 2019 to be a year where I learn how to chill. I tend to be kind of a busybody, so I’m trying to find more opportunities to take a step back, do some meditation, be more in the moment.

Ben Aston: And how many times in the last week have you managed that?

Alexa Huston: I don’t want to talk about my successful.

Ben Aston: Accountability is important.

Alexa Huston: Yeah.

Ben Aston: Oh that’s good. What I’ve noticed is that New Year Resolutions seem to be out and 30 day challenges seem to be in.

Alexa Huston: They’re very in. My gym is doing 30 day challenges.

Ben Aston: Yeah.

Alexa Huston: That’s a trend I’ve noticed too. Which seems better, in a way. Like it’s a little bit less of a daunting task if it’s broken up by month.

Ben Aston: By month, yeah. So maybe next month you can do 30 days of meditation.

Alexa Huston: Maybe. I could.

Ben Aston: You can always-

Alexa Huston: Too late to start for January, but maybe February.

Ben Aston: Well, good luck with that. I’m still trying to define mine. I decided that hey, I want them to be right. I mean, we’re a week into the year, but I don’t want to commit to something that I can’t commit to too prematurely. So I’m still working on that. But apart from your goals, what else is new? What else is new with your, tell us about Crema and what you’ve got planned this year.

Alexa Huston: Yeah, that’s a great question. Crema is, we’re growing like crazy. And personally, in terms of work, I’m getting used to working remotely for the first time, full time. So our team is growing, I moved down to Arizona at the end of 2018 and was lucky enough to stay on board as a Crema team member. So I’m adjusting to remote life, and thankfully, everyone at Crema has been super supportive. We actually have a couple other people that are distributed. And so between them and me and a couple people in our headquarters in Kansas City, Missouri, we have this little remote team task force.

You know, we’re all committed to making sure we feel connected to the office still, we’re recognizing what improvements need to be made, what changes need to be made, just making sure that we are still able to contribute to the culture and the culture can still serve us, even if we’re not under the same roof. So it’s been fun. It’s been a new challenge for me. It’s challenging how I think about my work discipline. I always thought it was, and then when you look around and you’re like, “Wow, I would really love to do that load of laundry, and you can.” I’m like learning how to say no to those distractions.

Ben Aston: No more laundry.

Alexa Huston: No, yeah. No laundry 2019.

Ben Aston: What are the three things then, that your task force, I came up with three, but you may come up with a list of 100. But what would you say for people who are making that transition to building a remote team, or were co-located and becoming remote. Tell us maybe three things that you found to be the most impactful things that you think would change your effectiveness or your feeling of connectedness to the co-located team?

Alexa Huston: Yeah, that’s a good question. One thing I’ve really liked, and this is super basic, but it’s building in time every week to chat with people about non-work stuff. Because I really miss, you know, I had some really good friends. I’ve worked there for three years that I moved away from and it’s easy, because we don’t work on the same projects and we don’t work on the same teams and the only reason I haven’t really talked with them so much is you know, they’re my friends and we sat close to each other. So now that I’m gone, I talk with them over Slack or do video calls and just catch up on life things, and that has made such a big difference in making me feel that I’m still part of the family.

Ben Aston: Yeah.

Alexa Huston: So that’s been a good one. Just like, making time for water cooler talk with the people that you know, you want to. And everybody. New team members, people who come on, things like that. Another one would be, oh, something we just did was really helpful. We’ve been using Mural or RealTime Board for our remote meetings, so it’s kind of like a digital whiteboard. And that’s been super cool just to help us create these interactive meetings when you’re in a computer looking at it. Because you can still create little post it notes, you can vote on things, you can move things around the Board collaboratively, so that’s been really neat.

Ben Aston: And that’s called Mural?

Alexa Huston: And the last thing … yeah, Mural. M-U-R-A-L. And then RealTime Board is another one. And then the last remote tip I’d say, be willing to create, we’re calling it a subculture, like a remote subculture. Because there’s, we have such a great culture that we’ve built inside, I’ll call it HQ again. But it feels a little different, it does. When you’re not in the office anymore and you’re connecting every day from your computer. So we as a remote team have tried to create this subculture where we are also getting together, finding ways that we can infuse our personalities into the day to day, even if we’re not in the office. And nothing has really come about that, but we’ve all talked about how we want to create our own little culture that helps support the bigger values and mission that Crema has as well.

Ben Aston: Yeah. Yeah I think I find remote working a real talent. I think particularly when you don’t get that face to face time, with people, it’s kind of like you talked about. Actually checking in with people outside of work just to have a chat with them is really valuable, but you’re leveraging there relationships that you had prior. In the situation that I’ve been in is just trying to meet people for the first time remotely. And like, trying to develop any kind of a culture when everyone is remote and you know, people are in different time zones. I think it’s a really big talent.

Alexa Huston: Yeah, it is. It’s no small task, that’s for sure. So if everyone is committed though and sees opportunity to experiment with different tools, we also use AppearIn, which is just a platform for people who want to appear on screen and be visible, that’s been helpful too. But you’re right, I am able to pull from the three years I had working with these people, but I know that’s not always the case. And it will continue to change as we bring on more and more people, because we’re growing a lot and even last week, three new people started and I just sent them Slack messages. And I was like, “Hi, I’m Alexa, I work with you but I don’t know when I’ll see you. Here’s a little about me, I want to know about you.”

Ben Aston: Yeah.

Alexa Huston: “Let’s find time to chat.”

Ben Aston: Yeah. Cool. Well good luck with that. And I want to move on to talk about the topic that I introduced at the beginning which is all about sprint planning meetings, and Alexa has written a really in depth post which kind of talks through the whole process and how we can do it. So like I said in the introduction, I think the real challenge though, we all know sprint planning is the right thing to do, but actually doing it right and making it effective, I think it can be incredibly challenging. Let’s just start for those who haven’t read the post yet, tell us, I mean what is sprint planning and why is it important?

Alexa Huston: So it comes from the scrum methodology, it’s one of the ceremonies or meetings that you should be having. But I think anyone can use sprint planning if you’re basically dedicating yourself to sprints of work, so when work begins and ends. But this is designed to answer the question: “What can we deliver in the next sprint, and how can we accomplish this work?” And those are two like super important questions that often times a ton of people have to work together to get to those answers. And the sprint planning meeting is the time to do that. We’ll probably talk about this more and more later, but there is so much prep that goes into it that if you don’t set time aside to prepare for this sprint planning meeting, it doesn’t really help. It might make things more messy.

So we’ll talk about some ways in which you can get prepared and you’re on the right foot before you say, “Yeah, we can do this. And here’s how we’re going to get it done.”

Ben Aston: Cool. So I think, one of the things you talk about in the post is yeah, bringing definition to, we’re about to start this chunk of work for the next couple of weeks say, got a two week sprint. And one of the things that you talk about is you’re getting some definition to that, so it’s not just a bunch of work. So you know, defining a sprint goal. By the end of this sprint, we want to have delivered some kind of value, something that’s going to be worth something to the client, and incrementally get us further down the road.

But what I’ve found so often, particularly at the beginning, yeah, particularly at the beginning of the project, it’s you know, when you’re building something from scratch, it’s hard to get to a goal that’s meaningful. So I can understand further down the line when you’re mid development and a product already exists and you’re just incrementally improving it. But how do you get to your … kind of any tips for getting to a sprint goal that’s meaningful while you’re building the thing out for the first time?

Alexa Huston: You’re right. And that can be tricky, especially upfront. When you don’t have a lot of experience to pull from, whether on the product or as a team. Because one thing about sprint planning is, it gets better the more mature a team is. And mature can mean, the longer you’ve worked together, excuse me. The longer that you’ve worked on this product. In the beginning, you don’t have that luxury. So I have found you just have to get real with people. It does help if you have a little bit of, you can play good cop bad cop, maybe with the product owner.

Essentially, you need to push the team to say, “What’s your gut instinct here? How much do we think we can do reasonably and realistically?” Because I think we all can agree there’s going to be those people who maybe over commit to things, and there’s those people who get nervous and they might under commit to things. So one thing that has helped me, especially in the beginning stages of sprint planning, is finding out of whatever stories you’re going to look at and consider for the next sprint, have the team identify, what’s the smallest, easiest story? And what is the most complex, most difficult story? And use those as a comparison point along the conversation, because as you go and you say, “Okay, if we want to commit to this too, is this something we can relate against either the super small piece of work or super big piece of work?”

And over time the conversation should help you like, put some constraints around that. And keep asking your team, “Do you agree?” If not, make sure that you’re giving people the opportunity to speak their minds and bring in their perspectives, because that part of the project can be really tricky because people might be hesitant to bring up their concerns. But hopefully, you’re able to create an opportunity for them to feel comfortable enough to share those feelings. So frequently checking in to say, “Does everyone agree? Does everyone agree here? Should we proceed?”

Because otherwise, you might miss an opportunity to get someone’s perspective that could change the sprinkle. So it’s just a frequent check point along that conversation to say, “Does this feel right? Does everyone agree?”

Ben Aston: Yeah. And I think, I find that there’s often a bit of a you know, attention there though, in terms of, the development team might be … the reason they’re excited about the project is often different to the reason that as a product owner, you might be excited about the project or trying to deliver. So how do you kind of get to that alignment and buy in? And I like this idea of saying, taking it with the team as you go, and saying “Hey, you know guys, does this sound right? Am I headed in the right direction here? Does this sound like a reasonable goal?” But how do you get there? Any kind of tips on how you get their buy in and how you kind of get them aligned with the product owner perspective on what’s going to generate the most value?

Alexa Huston: Yeah, so I’ve got a couple of different things that have helped. One is creating sort of a project vision statement. And having that visible during, well hopefully always visible, but having it written up on the board or up on the screen. Just to have everybody able to quickly glance over and say, “Okay, that is the purpose. That’s why we’re doing what we’re doing.” Because you’re right, there might be some different motivations for developers versus designers, versus the product owner. But if everyone can look up and say, “That’s why we’re doing this.” That would help get some sort of mutual alignment there.

Another thing I’ve done, because I’m not a technical person by trade, I’ve picked up a lot of technical tidbits over the years, but one thing I’ve done that helps with getting alignment is repeating what I hear in a really elementary way. Because that’s the only way I can say it. And so when you hear people talking, especially when it comes to the technical build of things, or maybe certain user experience considerations, pausing if you don’t sense there’s alignment and restating it in a way to say, “Is that what we’re talking about? Is that really what the goal is here?” And you might find that is true, or that might spark a conversation around how, we’re actually not on the same page. Like, let’s make sure that we are there. So you are kind of playing a mediator role, and simplifying it to make sure everyone is on the same page.

Ben Aston: Hmm. And I think a lot of you know, the purpose of what we’re trying to do here, in bringing alignment and buy in, and bringing this definition from the planning that we do before the meeting. Because I think if we just leave it to the meeting and try asserting this kind of vision and goal before we’ve talked about it at all with the team in that kind of group environment, it can be quite challenging. But if we’ve actually had a chance to chat with people beforehand, that can really help to grease the wheel and say, “Hey, developer, for the next sprint, I’m thinking about this, does that sound good to you?” And having had that offline conversation I find can sometimes help when you have a tricky team member who tens to think that maybe they know better, or they’ve got a different idea about where things should be headed.

Alexa Huston: Yeah, that’s so true. And it’s, I think the whole ironic part of sprint planning is it will only go well if you do planning before the sprint planning. Like you have to build in time to groom that back log, make sure that your product owner has done their due diligence to sort of pull in two sprints worth of work almost, and that they’re all ready to go. And that I think takes the most grit, is getting to that point where you feel like you are prepared for a sprint planning. It is not easy. If anyone tells you it is, they must be a wizard because there’s no other explanation for that. It’s tough and it takes time and effort, and a lot of people are spread too thin to really do it well.

So hopefully, your PO and you as a PM have enough time to work together to groom that back log with your client. Because the back log contains not only user stories and features but bugs, stakeholder feedback, customer feedback, a whole host of other things need to be in there, because they’re all a part of the working product. And so if there isn’t time built in to help prepare for the sprint planning meeting, what’s going to happen is you’re going to walk into that meeting, even say you have two to four hours set aside for it, you’re not going to have time to get through everything, estimate everything, and have an ability to walk away saying this is what we’re going to do, and this is how we’re going to do it.

Because you’re going to get through two stories and be like, “Well, I’ve got to go.” You’ll never have time.

Ben Aston: Yeah.

Alexa Huston: So it can be really tricky.

Ben Aston: Yeah, so how do you, when you’re in an active sprint, how do you do that backlog prep? So the idea is that I have the sprint planning meeting itself, our stories are already pretty well groomed. So you know, they’re pretty well defined, they’ve got acceptance criteria. The definition of done has been update if it needs to be. They’ve been sized in some way so we that we kind of know roughly if it’s even worth talking about including in that sprint. So how do you, when there’s an active sprint going on, who’s doing this? Who’s doing this estimating and having these discussions? Because it should be the team, right?

Alexa Huston: Right.

Ben Aston: But they’re in an active sprint. So how do you managed, or how have you managed that successfully?

Alexa Huston: Yeah. That’s a very astute point. Because after sprint planning ends, the team should be humming along to do their work. But there is also this element of preparation that maybe you consider when you’re building the sprint goal. And setting your commitment. If you know that you’re going to need a little bit more time from the team to help with the next sprint, bring that up in the meeting and maybe adjust how much you’re willing to bite off. Because you will need people’s input to help make sure that the next sprint. It’s kind of painful. It’s kind of like a never ending cycle because you can’t have people doing both things all the time. Because the team needs to be doing the work on the sprint, on their product as it progresses.

But you do need their input to help inform what’s coming up next. So to answer your question, what I have found is it’s really in the hands of the PO and the project manager to help make sure that they are working together with the client, whatever stakeholder team in the background while the team is mostly focused on developing the product, designing, testing, all of that. But build in increments of time where you can, maybe it’s after your stand up in the morning. Say, “Hey, we really need to touch base on this for 15 minutes. I just have a few questions about this piece of work before you start your day.” Finding opportunities to catch people when they’re not totally focused on something else will help make that conversation more efficient and allows them to get back to work sooner.

So it does take a little bit of like empathy and intuition to say, “When can I ask people to talk about this?” But you’ll, I think as the product progresses and the sprint progresses, you’ll find opportunities to be like, “Hey, can I pull you away for 10 minutes and chat about this, or can we have a 30 minute meeting? I just want to make sure we have our ducks in a row.”

Ben Aston: Yeah. One thing that I will say I’ve found helpful is just adjusting that sprint schedule slightly. So introducing a bit of a gap, or basically go into code freeze early or a release early in the sprint so that you leave maybe half a day of kind of unallocated time before the sprint planning meeting. So say for example, you do a code freeze, it’s kind of a rough two week cycle. You do kind of a code freeze on the second Wednesday, you try deploying that Wednesday night, or releasing that Wednesday night or Thursday morning, you have kind of Thursday to tie up any loose ends. And Thursday afternoon is kind of empty time, and then sprint planning is on Friday morning, so there’s half a day in the schedule. It shortens the sprint cycle slightly, but then it kind of builds and there’s time to allow people to actually chat about stuff and investigate things ahead of that sprint planning meeting. So that could be another way to do it.

Alexa Huston: Yeah, I like that idea a lot.

Ben Aston: It just reduces the sprint length. That’s the kind of downside there. But it’s a way to … especially when there’s a lot of ambiguity to the project, and people are like, it prevents you from going into a sprint planning meeting and saying, “What’s this? Why haven’t we talked about this yet?” It’s like, we are talking about this now. And like you say, if you’ve just got two or four hours to try and plan out two weeks worth of work in four hours, depending on what you’re working on, and it can be quite a tall order. So I think giving yourself enough time to do that effectively is really important. Because I think one of the things people think about when they’re trying to do a scrum project is, hey it’s agile, it’s scrum. We don’t need to do much planning.

The whole idea is that we kind of go with the flow and we don’t need to plan it out. But the reality is yes, you do need to do even more planning because you’re just in these two week cycles. And those two week cycle have to be planned out properly. You can’t just go in and start developing and I think there’s this kind of misunderstanding that hey, just because you’re doing agile and you’re doing scrum and sprints, that it must mean that you don’t need to plan very much. Actually it requires a lot of planning.

Alexa Huston: Yeah, no. That’s very true. I think maybe, people see agile as something where there’s no documentation for things or no requirement building and that’s also not true, you’re maybe just not committing as much time to that. But there still is this element of preparation that can’t be ignored no matter what methodology you’re using. You simply won’t get results unless you make a plan. And sorry to say, but you need to be willing to alienate the plane if it’s not working. And you won’t know that until you do a full sprint, and then you have a retrospective and say, “Okay, was that good, was that not good? How can we improve moving forward?” It’s just kind of the funny part about making a plan is that you have to be okay with it also not going to that plan. You have to do it. It has to happen.

Ben Aston: Yeah, it’s an ongoing thing. It’s not a one time activity. It’s an ongoing thing that you constantly have to course correct and pivot. So in the meeting itself, we’re trying to get to this point where we’re reviewing these back logged items and we’re trying to decide and get the team to agree on the sprint goal, we’re trying to get this alignment and buy in on that, and take the direction that we’re going to take for the next sprint. And we’re reviewing things in the back log and pulling them into the sprint back log and saying, “Okay, making sure everyone understands them, making sure that they’re sized correctly, and then trying to get the team to agree what they’re going to agree to deliver at the end of the sprint that kind of mutes that sprint goal.”

But one of the things that I’ve kind of found can be challenging, and this kind of comes back to the planning and preparation thing, is that often, we’ll get to that point, the reality is that we’ll get to the sprint planning meeting. We haven’t, the team hasn’t had a chance to review it properly. And so we get to this point in the sprint planning meeting where we’re dour hours in and we’ve only got a couple of user stories that have been sized and agreed on. But we’ve got you know, two weeks worth of work that we need to plan, so what often happens is that things just get turned into spikes where they say, “Okay, we’ll time box an amount of time to investigate, we’ll spend you know, a day investigating. Looking into this kind of new functionality that we don’t know how to estimate yet.” But any tips on how you kind of speed up that process of the sprint planning meeting?

So you don’t get too bogged down with all the details of all the stories and then end up with not enough work at the end of it all.

Alexa Huston: Yeah, that is a common problem. Try to think tactically, if I can make any recommendations. One thing I’ve done, this sounds pretty simple. But reminding people of the sprint planning coming up, not in an annoying way, but definitely in terms of, I don’t know, urging them to review things that have been made available to them. Because chances are, it’s very noisy. It’s a developer. Whether you’re working on one product or more. And I’ve tried to make it a point to just communicate, you know, just make sure everyone, we have our sprint planning meeting on Tuesday or Wednesday. Make sure you build in time to ask me questions or review the stories that we’re talking about.

Because you’re right. If you get in there, and it just turns out to be sort of a slog through all these questions and you don’t ultimately get anywhere then you’ve sadly, you’ve wasted several hours of time you can’t get back. That time is gone. And I don’t know about in your experience, if you’ve ended up scheduling a secondary sprint planning meeting. Or just, “Okay, well this is what we’re going to try to do.” What have you done in your experience with that?

Ben Aston: Yeah, I’ve ended up having to extend the sprint planning. Or in a bad scenario when that hasn’t been possible, instead of doing a two week sprint, say okay this cycle, we’re going to have to do like a half, a one week sprint. Because we haven’t gotten two weeks worth of work. But yeah, having to have an additional planning meeting, I think it’s important to, you can’t just skip the planning and say, well the stories are the stories and I’ll just make it up for you. I think going back to the whole point of this, the sprint planning meeting, we’re defining a goal. We’re trying to deliver value at the end of the sprint. We’re trying to get agreement on sizing those stories and order that, there’s a reasonable amount of work for the team to do.

So these are important steps to follow. Because otherwise, what we’ll do is if we load the sprint with whatever we feel like, we’re going to get to the end of the sprint and only a couple of the stories will have been finished, and then the team really quickly gets demoralized. And feeling like they’re failing because you know, they just feel like they’re not achieving anything. And I think when scrum works is when hey, we set these goals and we hit these goals and the team feels like there’s momentum, and that kind of success really helps drive the project forward.

Alexa Huston: I agree. And one other thing to mention there is if you find that there’s someone on the team that’s a little more vocal about things being vague or you see trying to step up and fill in the gaps, see if they’d be willing to join the pre-planning meetings too. Because in my experience that’s been optional for developers, but I’ve been in a project where there was one of our devs, he was just really good at this particular technical issue we were having and I could see it when we would talk about it and when we would be in sprint planning. And I came up to him afterwards and said, “Hey, do you want to be in some of the pre-planning meetings? You don’t have to commit to this if it interferes with getting your other work done. And that’s important. But do you want to come and sort of help us groom things beforehand on behalf of the dev team?” He was sort of their representative on that.

And it ended up working well on that particular scenario. So if you, my point there is if you find someone who keeps sort of filling in the gaps for the team or keeps speaking up, hopefully, hopefully to say you know, we need to fill these out a little bit more, get a little bit more clarity before coming in there, see if they’re willing to be that liaison beforehand. It might help.

Ben Aston: Yeah. I think there’s so much great stuff that you’ve included in the article. So I really encourage people to go check out the article and I think really that the take away for me really in this is, yeah the sprint planning meeting is important in and of itself, but actually probably what’s more important is the preparation prior to the sprint planning meeting. And we can’t think that we can just go into the sprint planning meeting and just be able within four hours or two hours to plan out this whole two weeks worth of work. It’s just not going to happen. So make sure that you spend the time doing the prep prior to the sprint planning meeting and it’s much more likely to be successful.

But Alexa, thanks so much for joining us, it’s been great having you with us.

Alexa Huston: Yeah, thanks for having me.

Ben Aston: As one of our DPM experts, as I mentioned before, Alexa is making an appearance in our upcoming course. It starts in February. It’s called Mastering Digital Project Management. And if you’re not sure what I’m talking about, but you know you need some PM training, check it out. It’s a seven-week crash course and it includes interactive video lessons, webinars, assignments, group discussions, the option of coaching sessions too. So head to DPM.com and get yourself signed up before the course fills up. And if you’d like to contribute to the conversation, comment on the post and head to the resources section of digitalprojectmanager.com to join our Slack team and you’ll find all kinds of interesting conversation going on there about all things digital and PM. And if you like what you’ve heard today, please subscribe.

Take a couple of minutes to leave an honest review for the DPM podcast on iTunes. Ratings and reviews are extremely helpful so please do that. It really helps us tailor the show and make it better. So it’s greatly appreciated. But until next time, thanks for listening.