Product management: Effective Scrum ceremonies
This talk is meant for product managers, engineers, and designers on full-stack teams. We cover how to keep your product journey on track by maintaining ceremonies focused on outcomes and not process.
When done right, these ceremonies help expedite a product to market. When done wrong (or not done at all), teams often experience a myriad of problems like misalignment between stakeholders, inefficiency for dev teams–ultimately, blowing up budgets and timelines.
Luckily, there's a better way, and this talk covers it.
Watch the talk:
Well, it's great to see some familiar faces out there, but I want to thank everybody for taking some time out of this nice Friday morning to come in, spend it with us here at Devbridge. My name is Tim Kearney. I'm the Director of Product Management here at Devbridge. This morning, we're going to talk about effective scrum ceremonies. Now, to level set on what we're going to get through here today, Agile Alliance has a two-day, $1,000, certified scrum master training that gets you a fancy certificate and some new acronyms for your LinkedIn profile. And we've got 20 minutes, and some coffee, and some carbs. So, we'll get through what we can get through here. These are the delivery ceremonies that we typically follow here at Devbridge. Release planning, backlog grooming, sprint planning, a daily stand-up, design review, architecture review, demo, retro, and launch prep.
We're really just going to focus on these four, the main scrum ceremonies that you would read about: sprint planning, stand-ups, the demo, and the retro. At Devbridge, we use a two-week sprint process, so you see here, on the first day of the sprint is when we're doing sprint planning. On the last day is when we're talking through the demos and the retros with the internal team. Everything in between is where we're doing daily stand-ups. That's where the team is focused on ensuring their day-to-day progress on everything that they committed to on day one during the planning.
Before we actually get into what the ceremonies are, let's just take a quick step back, talk about what scrum is. It's frequently talked about in software development. That's the context we're here talking about today. But at its core, scrum really doesn't have anything to do with software. It's really a risk management framework. It focuses the delivery team on adapting their process, on iterating, and being transparent about what they do to reduce time delays in this important feedback loop between client stakeholders and the team itself. We want communication to be as open and smooth as possible.
Risks, what are the risks we're talking about? I think they're probably obvious, if you're in this business. But budget. Let's say, I promise you your dream house. Do you want it? Do you want to buy it? You need to know how much it is, right? Anything that involves your wallet is going to involve you doing a cost benefit analysis of whether you want that thing or not. So, your end user, your stakeholder has committed a dollar amount in mind to get the product that they're expecting. So, it's critical that we stay on that budget
Time. I have a great idea. I thought about it on the way into the office today. It's a mobile app where I can get a ride from where I am to where I need to be by putting my location in on a map, and somebody picks me up and takes me there, and then, I pay the money. It's a good idea, right? Missing the market can be devastating to any good product. So, we commit to delivering some discreet product, that some amount of time, if we delay on that, we jeopardize business. It's important to keep time in mind. Time is a big risk.
If we're running out of time, you can throw money at it. Let's double the team. Let's put some more designers on the team, build this as fast, twice as fast as we could to save the time issue. But now, we run back into the budget issue. So, now, all of a sudden, we're not going to have enough money to deliver the scope that we committed to at the outset. Under-delivering on scope is a big risk that scrum, or really any sort of agile process, attempts to solve.
How does it work? When we're going to build a product, we identify a backlog, all the things that we need to do in order to create that product in some order. In scrum, we want to work on these things in discrete pieces. So, there's a sprint backlog, which are the pieces that we're going to work on now. And we're going to iterate over this process over any number of sprints, depending on the level of complexity of the product. Each time we take a new slice of the product, do our sprint work over one week, two weeks, four weeks, however long your sprint process is. Here at Devbridge, again, two weeks. There's that separate iterative loop where when we're in the middle of the sprint, we're making sure we're achieving the goals that we had set at the outset. And then, at the end, we deliver some discrete amount of work that is potentially shippable.
I like this quote from Dwight Eisenhower because I find myself to be more of a results-driven person and not a process-driven person, and this is a process-driven talk. But I think scrum really provides a framework. It's a process framework for delivering. It's really up to the members of each individual unique team. The players on the team, what the product is, to determine how they should use that framework to their advantage. So, it's not going to prescribe very, very specific things about how to build the product, it's a framework to follow so that you're delivering what you need to deliver. That's going to vary very, very much based on who's on the team and what the product is.
Ceremonies, or sometimes, they're called rituals. They're just meetings. They're just meetings. Why don't we call them meetings? People hate meetings, right? Everyone hates meetings. I think it's a good word choice, ceremonies, because it conveys more importance about it. If you think about a knight in a medieval ceremony, committing to a king. Or college graduation and everyone getting together and celebrating what they've accomplished. Or even manage, right?
To graduate from college or to get married, all you really need is a piece of paper. You go down to City Hall, or you get the diploma in the mail. You're done. Doesn't really change anything as far as what needed to happen to be graduated or to be married. But we do these things to give them greater significance and to commit in public to what it is that we have either achieved or we want to achieve. And that's how a team needs to work in delivering a complex software product. We're all in the same boat together. We all have to be honest with each other about, are we achieving what we said we were going to achieve in a daily basis or on a sprint-by-sprint basis, both within the team itself and to the client, to your stakeholder.
Let's talk about some of these ceremonies themselves. Sprint planning, it's the first one that we talked about. When we look at these attendees on the list here, at Devbridge, a product manager is typically the scrum master. So, if you were to read scrum-specific documentation, the scrum master has a significant level of responsibility in these processes. Here at Devbridge, that falls on the product manager. But the purpose of planning the sprint is to figure out, hey, what is it that we're actually going to deliver in this iteration, in these next two weeks? We should not go more than four hours in a two-week sprint. All of these things should be timeboxed. It's an important component of scrum.
Timebox for two very specific reasons. One, the old adage, time is money. Every minute you have people in a room talking about something is a minute they're not working on the product. But second, it also should help focus you on what it is you're in the room to talk about. Every specific ceremony has a very specific purpose. You have to really take care to not go down rabbit holes. These things can be complex, and it's very easy to do so. So, staying on track is important.
Prerequisites to have a successful sprint planning meeting, you have to have a groomed backlog. What does that mean? Your backlog could have hundreds and hundreds of stories in it. Those need to be prioritized in advance. You can't be sifting through the entire backlog trying to figure out, what are we going to work on now? You should already know what the most important things are that you need to conquer. You should also have a size of those stories. An estimate should be already assigned to each story so you can figure out how much can you actually deliver. You're going to look at your teams, what's called velocity, how much complexity can be delivered in any given sprint. And so, to do that, you need to know how many of these individual stories is possible to do in two weeks.
You don't want to over-commit. You also don't want to under-commit. What happens in here? The scrum master or the product manager presents that backlog, reviews it with the team, makes sure everyone's on the same page before we all commit in public to our stakeholder what it is that we're going to develop. These stories, now, may need to be broken down into further tasks. Let's say the story is something like, you want to add a middle name to a registration form. We already have first name, last name, we want to add middle name.
There's a couple different things that have to happen. Yeah, there's a UX change. We have to add an input field. We also probably have to add a database column or something somewhere. We probably also have to add some changes to some API end point that we're using to submit data to. There are multiple things that need to happen in order to accomplish a story. And in sprint planning is when we might go through all those things and figure out, break these things up into more discreet chunks to make sure everyone's aligned to what needs to get done.
But at the end of the meeting, what everyone should walk out of the room with is not only an agreement on what it is we're going to be building, but what is referred to commonly as a sprint goal. Why are we building these things? Are they just ad hoc components or requirements that we're just putting in for because they happen to be at the top of a list? That shouldn't be the case. We should be trying to solve with a very specific, to the extent possible, a specific use case in the deliverable at the end of the sprint.
And that also allows the team to understand high level what it is they're trying to do. If they're just focused on the details of an individual story, it doesn't give them a lot of flexibility. All they can think about is, this is what I'm being tasked with to accomplish. Whereas, if they're aware of a larger sprint goal, say, a sprint goal might be augment the registration page for a future data integration with some API, just a high-level thing that is an umbrella over all the stories going on. That gives them a little bit more flexibility to achieve that goal, even if they can't achieve what's specifically in a given story. And that's important.
Also, doing that might help you achieve the goal of the sprint, but introduce something like technical debt, which is a totally separate topic, but maybe, it makes sense for your team to take a shortcut to achieve the goal that's necessary to not be a blocker in future sprints, but you didn't do exactly what the story said. A sprint goal is important in giving developers an out to see the bigger picture, instead of just trying to do what is in that individual story or sub-task to that story.
The daily standup. This is really important. This is happening every day. Shouldn't be take more than 15 minutes for the product manager or the scrum master to talk with all the developers and designers on the team to figure out, did people do what they said they were going to do? What you need to have is your Jira board, or whatever board you're using, needs to be updated to reflect the current realities, to make sure everyone's on the same page there. If work is getting done and it's not getting updated properly in your tracking tool, then people don't know what's getting done. This meeting's going to be less effective. But what did you do yesterday? What did you plan on doing today? And is there something that's going to prevent you from doing what you said today or that prevented you from doing what you said you would accomplish yesterday? Because we need to identify who and what is needed to do to remove those blockers.
It's also important to understand if something didn't happen yesterday that you thought would happen, why? And the why is important. Was it that it was just more complex than you thought it was? Or was it you were out sick? Or was it, you were too distraught by the ending of Game of Thrones, then you just couldn't focus? The reason is important because if it's continually a case where the complexity was greater than anticipated, that needs to be brought into your thinking for all future sprints. Maybe all these things are undersized somehow. This is a problem.
If it's a temporary thing, like we couldn't get into the client's development environment, then that could be catastrophic for one day. You know it won't be a problem today, but it's something to keep in the back of your mind to push back on your client, hey, if your environment's not stable, it's going to cost us. If it's just somebody's out sick or somebody went on vacation, then you can understand that and know that it's not necessarily going to affect future sprints the same way some other things would. Understanding what is slowing you down is really, really important. And it's really important for the team, especially the development team, to raise those to the product manager so they're aware.
The demo. Now, the end of the sprint. You've worked for 10 days, made a commitment. Now, it's time to show off what it was that you did. Did you accomplish those goals? And get feedback, really is the most important thing. The daily stand-up isn't a critical feedback loop from the development team to product manager to make sure the commitments are being made. The sprint demo is that same feedback loop, larger, making sure that the client agrees with what you're doing, can give you important feedback.
Maybe part of the scope was missed or misinterpreted. And now, you have additional backlog you need to add because you just found out in your demo, oh yeah, we didn't think of that. You don't want that to happen, but that's why the process is important. Find out sooner than later. It's also important to think about raising concerns immediately. If the product manager is aware of where you are in your total release plan. Maybe you're in sprint three out of 30 or your in sprint nine out of 11. Where are you on the path? Are you on track to meet whatever release goal was made? Again, those risks. Budget, are you still on budget? Are you on time? How's the scope? Has it grown because you keep missing and you keep adding things to the backlog, or everything's going well there?
But if you're especially early in a project, you want to raise those issues as soon as possible. The client needs to be aware. Bad news is sooner, is better now than later because there might be a chance to make a change that doesn't actually end up being that painful. Maybe there's part of the scope in your MVP that the client was insistent on at the outset. Now, they realize time is in jeopardy, budget is in jeopardy, actually turns out we really don't need that. Let's just cut it, and everything's going to be fine. You need to let them know. They can't make that kind of decision to help you if they're not aware of what's going on. So, papering over problems has to be a non-starter.
Last, after the demo, as part of this iterative process is the sprint retrospective. The whole team gets back together. After they've shown off their work, hopefully, feeling a sense of pride, figures out how did things go in that sprint? Let's look at the sprint, the plan that we committed to, the items that we committed to. What percentage of them did we hit? Why did we not hit some of them, if we didn't? Transparency is important. So, if the development team feels like they didn't complete the story points that they expected to because the requirements, the story put in by the product manager, or the scrum master, or whoever it was, if that was not detailed enough, that needs to be raised as a concern. Maybe there's somebody else who can help. Maybe we can bring in more resources to help vet the stories before they land in a developer's lap, and then, there's confusion.
Maybe there's just interpersonal friction that needs to be sorted out that's slowing people down. These are real problems. People have a hard time with other people sometimes. Our commitment, as a team or as a company, has to be to developing to the customer. So, if there are problems, we need to hear about them. Let's get through it. Those are difficult conversations, but better to deal with things upfront and transparently than just have a, maybe, slower velocity than we should have because somebody doesn't want to help collaborate with somebody else. Maybe we swap out a team member. The point is transparency is really, really critical. Just showing up and doing your job doesn't necessarily get it done if you're having problems for any reason.
What should come out of this meeting is how do we do it better next time, this next sprint? How do we either avoid the blockers that got in our way? Maybe push back on the client to get us access to something we didn't have access to. If we're having problems again, say, with pushing into an environment and it's causing a lot of frustration amongst the team, raising that so that it can be raised back with the client is important. Everyone needs to be open about what's going on.
Now, what can happen to these retros over time is they can, maybe, get a little repetitive, especially if you're like, maybe there's not a problem. One thing to think about is varying the formats of them. Commonly, you might look at a retro and say, "What went right? What went wrong? What should we change?" Maybe that doesn't elicit the feedback that you need. Maybe somebody's frustrated, but they don't really feel like they're empowered to change the process, so they don't say anything. And then, you don't know that they're frustrated. So, consider changing the format of how you're asking for that information.
Maybe switch it into emotional terms. What are you glad about? What are you mad about? What are you sad about? Then you're not asking for a process prescription. You're asking for just how somebody felt, individually, and that might help you figure out where there are process problems. Wins, worries, wishes, just twists on the same sort of thing. Come up with a two-axis quadrant system of loss, gain, pleasure, pain. Find ways to get people to communicate, especially as they get repetitive over time. Because unlocking where people are frustrated to improve process is the name of the game in scrum.
In summary, software development is pretty complex, and it's really, really important that a team stays really tightly integrated, transparent with each other in communication to keep those risks in check: schedule, budget, and scope. And those four ceremonies that we ran through, the sprint plan, the stand-up, the demo, and the retro, they're all critical. You have to be focused on the tasks at hand, but you also have to be focused on the people involved. Make sure everyone is open and honest about what's going well, what's not going well so you can improve over time, and ultimately, deliver in the end your release to your client. Thanks.
About the event:
Full Stack Friday is a monthly, meet up hosted by Devbridge at our Chicago headquarters. We get together to indulge in a delicious pancake breakfast and talk shop. We bring in guest speakers to present talks focused on issues relevant to product people and full stack teams. For more information about the next event, contact us directly.