Sprint Planning Webinar Recap

Thank you so much for spending your lunch hour with us. I hope you got your questions about Sprint Planning answered and benefited from listening to other questions asked by the group. If we didn’t get to your question or maybe you have a follow-up question, ask them in the comments below.

The recording and transcript can be found below. Full disclosure, we forgot to hit record at the very beginning (sad) but got the tape rolling before the Q&A started (yay!). We included a recap of the first 15 minutes below with the slides.

In the next tactical webinar, we cover Retrospectives.

Agile Sprint Planning Webinar Recording

Agile Sprint Planning – The Quick and Dirty 101

Every iteration, we get together as a team to talk about what goals our Product Owner has for the team to conquer – what value can we produce, or what hypothesis we can test. We review the stories our Product Owner thinks will help meet the goal, and then we collaborate about how we as a team can deliver. We talk about the tactical tasks we need to do in order to accomplish our goal. This is Agile Sprint Planning.

We typically take two hours for every week in our iteration: if we have a two-week iteration, we plan for a four-hour Sprint Planning ceremony, and a four-week iteration gets eight hours of Planning.

At the end of Sprint Planning, we have a great idea of how to achieve our Sprint Goal and have made a commitment to get it done. However, when we’ve been coaching, a common theme we see is that teams are afraid of actually committing during Sprint Planning.

3 Agile Sprint Planning Antipatterns

• Fear of Commitment

We can make a few relationship jokes here, but so many teams have a true fear of truly committing to the work of the sprint. The Sprint Commitment is a crucial part of team empowerment and getting to predictable. The business is saying we will be hands-off your Sprint and we are empowering you to do whatever you need to do to get these things done. The team holds themselves accountable to delivering what they said they would. There shouldn’t be a fear of reprisal. This isn’t deliver or else. This is us taking the initiative to dig in and really try to get something substantial done while maintaining a sustainable pace.

Here are a few of the things that we consistently see or have seen that have that keep the team from really feeling like it is their commitment allowing them to really feel accountable to it.

The first one is the sprint being planned out before the team walks into Sprint Planning and all they need to do is give the thumbs up. If that happens, then whose commitment is it really? Right, not the teams. Then when they don’t get it done they are most likely gonna say something along the lines of, “well we thought that was a dumb idea anyway. We never thought we could get it done.”

Not actually “committing” is another thing we see. The team is like, “Yeah eh, maybe we can get it done.”  There’s not a shared commitment around the room. The team truly, All hands on deck, “yes we are going to commit to doing this.”

One of my favorites. Capacity is determined based solely on estimates with no discussion around the actual work. “Our velocity is 22, so pull 22 points in and ship it!” End of discussion.

The over-estimaters: “Let’s pull in 25 points!” The ScrumMaster comes back with, “Guys, your velocity has consistently been 20 points, but you keep trying to pull in 25. Did something change this sprint? Did you do an experiment that made you 25% faster? No? Then let’s pull in less and get to truly done. Then if we get close to the end of the sprint and we are really done, done, we can pull something else in that we think we can finish.

Or the under-estimaters: These are either the chronic sandbaggers or the ones that are afraid of getting in trouble for not finishing. “Hey Reese, you told us the goal was to get done. That last one could put that in jeopardy.” To which I usually try to encourage them to dig a bit deeper and strategize how they could complete everything.

The last one, that will tie us into the next set of anti-patterns is the team fully committing and starting the sprint without tasking as a team.

• Tasking Antipatterns (three antipatterns in one)

When working with teams that are having problems meeting their commitments – to themselves and to the larger organization – we commonly find problems when teams are trying to task.

As we work together as a team and build a stable velocity, we begin to trust how much work we can accomplish every iteration. Taking the time during Sprint Planning to break our work down into small tasks, though, is like wearing a belt and suspenders, or like trust-but-verify. We take the time to recognize that while we trust ourselves and our past performance, there’s always a chance that we’ll find something new – a new problem or a new solution – that breaks the mold.

Another pattern we’ve seen is that teams start to look for ways to make Sprint Planning more “efficient” – for example, the lead developer in a certain area creating and estimating all the tasks for a certain type of work. While this can help Sprint Planning go faster, that’s never the point; the point of Sprint Planning is to collaborate as a team and work together to figure out how to meet your Sprint Goal. If one developer does all the estimates and tasks for “their” work, you end up with a single point of failure – when she takes a vacation, suddenly you find that your team’s estimates are all wrong, and your Sprint Goal is in jeopardy.

In order to find more efficiencies, we’ve seen teams – especially teams using a tool that makes this easy – start to build out “placeholder” or standard tasks, and filling in the tasks for certain types of work automatically. While this can speed up Sprint Planning, you’ll still miss out on the conversations you need to think through new ideas and new ways to solve problems, and likely miss opportunities to work together to find ways to improve.

When you’re creating your tasks – tasks small enough to see daily progress in your Sprint Burndown, tasks from about a couple of hours to no more than a day or two – you’re verifying that you understand what you need to do as a team and have more confidence in committing to your Sprint Goal.

However, in order to do that, you actually need to have a Sprint Goal.

• No Sprint Goal

The Sprint Goal is the ONE thing we are truly trying to complete in a Sprint, yet we see a lot of teams that don’t have them. Why? Some teams believe that the goal of the Sprint is to try and get stories completed. False. Just like the goal of a quarter shouldn’t be to get all the projects done, the goal of the Sprint shouldn’t just be to get all the stories done.

A better goal would be, for example, “completing the upgrade process.” If this is the goal, then stories pulled in should support that goal. When you hit the end of the Sprint the product owner can assess if a few tiny things left prevent the team from meeting the goal or if they can move on. Sprint Goals allow PO’s to be ruthless with their prioritization.

Questions Polled From Past Agile Velocity Certified ScrumMaster Workshops

Q: Should you do a daily stand-up the same day that you do a Sprint Planning?

Reese: Sort of. You probably shouldn’t have it as a separate meeting–you don’t want the team to have standup at 9:00am then go back and try to get into something for 45 minutes then Sprint Planning at 10:00am. Usually, teams start Sprint Planning with a quick review of the status of anything that wasn’t completed by review. The last ten or so minutes of planning they strategize a game plan for the day.

 

Q: What does the Scrum team do after Retro and/or Review before Sprint Planning? How far in advance of the Sprint does Sprint Planning happen?

Braz: There a couple schools of thought on this. One, the team can start preparing for the next Sprint. Another option is that they go home….and that’s OK and that needs to be OK.

 

Q: No features added to Sprint once it began? How do you respond to changing requirements that are urgent and important to customers? Two weeks can sometimes be a long time to wait.

Reese: The Sprint should only be as long as the business can keep from changing their minds. If by nature, the work is interrupt-driven or just can’t be planned like support or ops work, maybe Scrum is the wrong framework for your team. Something with a continuous flow from a prioritized queue like Kanban may fit better. If you *should* be able to plan, but you have some cultural issues around trust, then it’s time to reset expectations and do some training.

 

Q: When holidays and training are foreseen and we have an average velocity we plan for, should we plan for less velocity when everyone is out of office?

A: Yes, absolutely. Let stakeholders know that for this time period, Christmas for example, the team is planning for a lower velocity. If the stakeholders know this in advance, they are given the opportunity to plan accordingly.

 

Q: During Sprint Planning, should there be a threshold number of tasks under user stories? If yes, should there be another user story created?

Reese: Break down your stories. If you don’t think you can’t get it done in a Sprint, then you should break that down into a different story. Somewhere between 4-6 stories per Sprint is the general rule of thumb. You don’t want so many that you’re doing a bunch of context switching. You want subtasks to be between half a day to 2 days so if you have more tasks than people days, you probably have too many.

Braz: Maybe the stories are getting to be too big. Follow your gut. Take a moment to ask yourself “Is this getting too complicated? Do we still understand what we’re doing? Do we still understand the value we’re providing?” If not, break down your user stories into smaller stories, not necessarily subtasks.

 

Q: What are best practices to handle carry-over work? Especially related to estimating remaining work and taking credit for completed work?

Braz: So, we get into our Sprint Planning session and with the best intentions, we say “Here are the things we’re getting to get done.” We work and work, but at the end of the Sprint, nothing is done. Now we have carry-over work that will–possibly–be moved over into the next Sprint.

The first thing we do is recognize that we don’t get partial credit. We only count velocity in terms of our ability to deliver value to our customers with predictability, not our ability to predictably keep busy. Even if we’re actually getting stuff done, it doesn’t count if we didn’t complete the work we set out at the beginning of the Sprint.

That being said, we’ve put effort into this and if our PO decides to pull this forward, we might continue working on it in the next Sprint. However, the PO has an opportunity to react to changes in the market before deciding to continue. Now, the team can re-estimate the work without changing the size of the story. You’ll notice over time the velocity levels out. The stories are the same size, it just took a little longer to complete.

 

Q: What’s the role of the “Definition of Ready” in Sprint Planning?

Reese: This isn’t technically a by-the-book Scrum practice. It’s something that’s come up in the last few years as teams have wanted to get closer to predictable.

Some teams want to define ready just like we do with done. Defining ready is all about deciding what things need to be checked off before an item is pulled into a Sprint. These things can include “item is estimated”, “dependencies have been knocked out”, “all questions are answered”, “design and team have initiated some sort of visual mock”, etc. Your Definition of Ready really depends on individual teams because it’s all about defining what you need to be nailed down in order to get to predictable.

 

Q: Do you factor in time for the look ahead/grooming sessions (multiple per Sprint)?  And should the look ahead/grooming be with the entire team or just 3 amigos (to keep the team in flow)?

Braz: When we talk about the ceremonies in Scrum, backlog refining isn’t an official ceremony. However, a team (especially when a team is getting started) should absolutely reserve the time necessary for things like refining the backlog. Almost as much time, if not the same amount of time, that they set aside for Sprint Planning.

When you first start out, you probably do need the entire team involved because of the number of perspectives both in terms of expertise and of skill level. Once your team has started to really gel and flow, you might be able to bring it down to just the three amigos– meaning a PO, a developer, and a tester to ensure that you maintain varying perspectives. However, it would be a good idea to periodically switch those individuals out to keep perspectives fresh.

 

Q: We do big room planning every quarter to break down features, create stories, and estimate. What is the place/scope of Sprint Planning in this case?

Reese: Backlog refinement isn’t necessarily a traditional Scrum ceremony. However, that big room planning is kind of a higher-level backlog refinement. Just like with a normal, every sprint backlog refinement session, you still need a Sprint Planning session to really dig into to tasks and break down what needs to be accomplished within a single Sprint as opposed to within an entire quarter like you would in a big room planning meeting.

 

Q: What if POs are not attending the planning sessions, and the Technical Program Manager is running the show?

Braz: As a coach, the first thing I would ask that Technical Program Manager and PO is if that PO is really a PO. A PO needs to be able to do 3 things:

1. Be available to the team – If the PO isn’t available, the team will be slowed down because they’re waiting to hear back from the PO and will, therefore, lose predictability.
2. Be knowledgeable – The PO needs to be able to answer the team’s questions. They need to have a little technical expertise and an awareness of what the customer specifically needs.
3. Have the authority to make decisions – It doesn’t do any good if a PO tells the team the items that need to get done, if someone is going to come along and override them.

If you don’t have all three of these, then you probably aren’t actually the PO. So the question becomes does the PO want to be PO? Or do they want to let someone else take over that role while they fill a different role?

 

Q: Our release is six weeks and we have a model of six Sprints that last six weeks as well. How do we get out of this antipattern?

Reese: So the simplest answer is that you don’t have to release every Sprint. Your Sprint is attempting to get you to a potentially shippable product increment. That doesn’t mean it necessarily has to be shipped. You just need to be hitting your definition of done and to be in a place where you don’t have a ton of extra work. You don’t want to do 6 weeks of Sprints and then half a Sprint of unfinished work. So you don’t have to tie your Sprint to your release cadence.

 

Q: Should the team look at the product road map (if you have one) at the end of the Sprint to evaluate product launch risks & Sprint goal validation?

Braz: Yes, that’s a great idea. This reinforces the idea of a Sprint goal. We have those for your customer advocate, your business representative, for the PO on your team. It expresses the customer-facing problem that you’d like to solve and what you’d like the team to focus on. Then, it creates the space for your team to come up with some innovative solutions to that problem.

Your roadmap absolutely talks about the features and functionality of things but it also needs to start incorporating how to solve these customer facing problems. The roadmap becomes customer facing problems that we need to solve versus functionality that we’re going to release. That’s when it absolutely becomes incredibly helpful to have that roadmap to refer to in terms of reaching the goals that we’ve set out to accomplish.

 

Q: What is the best way to size tickets? Should it be in terms of hours, business days, story points, etc?

Reese: As humans, we’re pretty darn terrible at estimating hours and days, but we’re really good at estimating things relative to another. We can tell when one thing is smaller than another, or that this thing is 2x as big as this over here. That’s what we try to do with our work and that’s kind of where story points come in. Story points are a relative number that encompasses size, effort, and risk that we give to our work to help us estimate.

A lot of teams do tasks in hours, which is fine. If you’re off in your estimation by a few hours, it’s not that big of a deal. However, when you start to estimate in larger amounts of time like days or weeks being off in your estimates starts to become more damaging and there’s a potential to put the Sprint at risk.

Braz: It’s all about getting your team on the same page.

 

Q: In Sprint Planning, how do you estimate time (number of hours) for allocating maintenance of the product and enhancement of the product?

Braz: This is a coaching moment for the PO. We don’t create a Scrum team to focus solely on new features and functionalities. I’m creating a Scrum team to own a product. And that product backlog includes everything, all the works visible–even if it is maintenance or enhancements of existing products. So you don’t allocate time for maintenance, you treat maintenance just like you would treat new features and functionalities: you put it in the backlog and let the team estimate the work. It also needs to be prioritized in the backlog and evaluated by the value it brings the customer just like new items would be.

 

Q: What if the team realizes that a story was too big and we refactor/split story? Does it count if we refactor the Sprint goal, also?

Reese: A Sprint goal doesn’t have to encompass completing an entire segment of the work. Something like an upgrade process could take 3 Sprints. In that case, you want to break that goal down into pieces that will fit into a Sprint. Really think about what you can realistically get done in that set time period instead of just getting some of it done.

 

Q: What’s the value of estimating both user stories (in points) and tasks (in hours)?

Braz: So we touched on this a little bit earlier but I say go for estimating in some form of relative measure. Whether that be the Fibonacci sequence, estimating in shirt sizes, powers of two, or whatever as long as it’s a non-time based estimation.

The value is two things:

1. It gives the PO some visibility into the work in the backlog and gives them a relative idea of your velocity as a team. They can then begin to see where they can group things together and begin to prioritize based on those relative estimations.
2. What happens when your team gets better or you suddenly gain automatic testing? When those things happen and we estimate in time, we’ll have to reestimate everything because the old estimates are no longer valid. On the other hand, if we’re estimating in relative terms, then our estimation is still just as good. Our velocity just went up because now we have more capacity.

For tasks, it really is trust but verify. As the team gets better and better, they may not spend as much time estimating tasks because they just know. But there’s always going to be that one user story that has something you’ve never seen before. In that case, the team needs to know when they might need to go back to estimating in hours again. That would give you the visibility to say “If we have x number of hours available to us over the next week, how likely are we to actually get this done?”

 

Q: We [UX] work so far in advance that usually, we’ve got assets on the shelf for Scrum to pull down. What’s starting to happen is that Dev is getting behind and then the assets need to be revisited for any number of reasons even though the PO thinks he’s got all this design work “done” which isn’t really accurate. We used to be involved in release planning and showed POC/high-level wires, but now those meetings are too late in the timeline for us. So I’m trying to determine a more collaborative approach. Advice?

Reese: I hate to say it, but you’ve got to get closer to the team. It’s not that Dev is getting behind, it’s that you guys are getting way out in front. Dev is working at the pace they can and you guys are there as part of that team too. You should have one foot in the Sprint and one foot in the Sprint before– but not months before. You want to be there really making sure that the next things in the backlog are ready to go.

We were once in a land of product delivery, and we need to shift ourselves into a product discovery mindset. We have to know that things are going to change. As soon as we get in there and start putting fingers to keyboards, we’re going to learn things. We want to get things out there and in front of customers as fast as possible, so that we can tighten that feedback loop and shift as we learn more.

If you’re doing things so far out in advance, not only are you not going to be benefiting from your real-time customer feedback, but you’re also going to get a little white-knuckled. That’s because you’ve already done a lot of work. If you do learn something new from feedback, you’ll be hesitant to shift because of how much work you’ve already done. However, that’s not the world that we live in. We live in a fast-paced, quick-to-change world, and we want to be ready for that. That’s the real goal.

So bring it in. Get a lot closer to your team. You really want to live in that 2-3 Sprints out zone, where you’ll be doing your backlog refinement. Then you want to figure out how to test features as soon as you get them so you can get in front of the customer.

Braz: Not only will you have to respond to customer feedback, but you’ll need the flexibility to respond to changes in the market as well. You never know when changes will come about.

Also, don’t be afraid to get out of your comfort zone. If you’re really comfortable doing UX, but the rest of the team is falling behind, it might be time to step back and see what you can do to help the team out.

 

Q: What’s the difference between a Technical Product Manager and a Product Owner? My company only has TPMs.

Braz: I don’t care what you really call them. From a title standpoint, it doesn’t really matter. The role of the Product Owner, however, is pretty explicit in the Scrum Guide. The person that plays that role, whether that’s the TPM or the PO, needs to be the person who is ultimately responsible and accountable for the decisions that need to be made around the things that should be delivered.

They need to know the customer value that the team is working on and what things are being delayed. The person in that role also needs to be available, so when the team has questions they know who has the authority to tell them what they should do. This way the team can keep delivering on a regular cadence and maintain predictability.

Regardless of their title, if someone can be available, has the knowledge, and has the authority to make decisions, they can wear the PO hat. Anyone from any part of the organization can fill the role of PO if they have those three things.

 

Q: How does Portfolio Management benefit and/or impact our Sprint Planning?

Reese: There are going to be tons of benefits and tons of impacts. But the one thing to make sure you don’t have happening in your organization is that Portfolio Manager just handles the Portfolio Kanban and/or roadmap and tells people when they’re going to do things.

The PO and the Portfolio Manager work together to make sure that everyone is on the same page and that expectations are being set. There be impacts when something shifts or something comes up, and that does happen. If that happened between backlog refinement and Sprint Planning, you may have to do some refinement either at the beginning of Sprint Planning or in a new session. You have to prepared for things to change sometimes. The big thing is making sure that there is a very, very solid line of communication between those two groups (the PO and the Portfolio Manager).

Braz:  When Portfolio management is done well, it provides clarity and a sense of purpose, and it makes that Sprint goal crystal clear on an organizational scale. They help create alignment.

 

Q: If we estimate stories using points, is there value in also estimating tasks for each story?

Braz: Maybe. I don’t mean that to be a wishy-washy answer, but I’ll answer your question with a question: How are you actually delivering on every Sprint? Are you getting everything done? Do you have a level of predictability? Are you at the point where you can say that you have a stable velocity, and you understand what’s going to get done, and we’re correctly sizing things every Sprint without sandbagging?

If yes, it may not be worth it. You may not need to make those tasks because you understand what comes up every single time. I would just keep in mind, when things come up new, keep that task level estimation in your back pocket. Trust but verify, so that your team will still know what’s going on even in light of that new, unexpected thing.

 

Q: We do native mobile development, so we have android and iOS. A lot of times, that feels like two separate teams. Any best practices around planning with two “sub-teams” in a Scrum team?

Reese: I was actually a Product Manager for an Android and iOS team once upon a time, and it was a challenge to keep them on the same page. We actually had them as two separate teams. There was a lot of confusion around one team learning something and not telling the other team or other things along those lines. So you want to make sure that if you are going to have those as two different teams or “sub-teams” that you do meet together. Do things like backlog grooming together and even some Sprint Planning.

From the sound of this question, you guys really do have Android and iOS as one “Mobile” team, and sometimes it can likely feel like you’re dividing meeting time to talk about two separate groups of work.

So a best practice is to really make sure that you are talking about those stories that really do apply to both the Android and iOS application because they are vertically sliced. So, you really want to treat this team like any other scrum team that is working on a vertically sliced product increment: something that is valuable and independent. They’re all playing their part in the team.

But take this question to the team. See what works. Retro on it so that everyone is getting what they need and you guys as a collective team are coming up with solutions.