Our little three person team doesn’t use all of Scrum because it doesn’t fit our context. And your context may not require that you use all the parts of Scrum either.
When you’re trying to improve how your team works, it’s natural to ask, “Do we really need this part of Scrum?”
Maybe your team meets every day and the Daily Scrum feels redundant. Maybe your stakeholders aren’t showing up to Sprint Reviews. Maybe the Product Owner role is split across several people.
In this episode, we walk through each part of Scrum and answer two key questions:
- What job is this element designed to do?
- What do you gain by including it—and what do you risk if you skip it?
If you’re working in or around Scrum and want a clear, thoughtful way to evaluate each part of it, this episode is for you.
Resources Mentioned in this Episode
Episode Transcript
Peter Green: Scrum is one proven way to do a set of jobs that pretty much every team needs to do, whether they use Scrum or not. It provides one answer to questions like, how will we coordinate, how will we improve, and how will we decide what to focus on next? But how much of Scrum do you really need? Well, Ken and Jeff, the co-creators of Scrum, would say it’s all or nothing, and that’s their prerogative, they created it. But our little three person team doesn’t use all of Scrum because it doesn’t fit our context. And your context may not require that you use all the parts of Scrum either.
Richard Lawrence: So in today’s episode, we’re gonna describe the jobs each piece of Scrum is meant to do, which pieces we’d recommend everyone consider trying, and which might be more context dependent.
Richard:If you’re curious about whether to try Scrum or if your team is using parts of it and you’re wondering if you’re doing it wrong, this episode’s for you.
Peter: But first, a quick reminder that this episode is brought to you by us at the Humanizing Work Company, where we help organizations improve their leadership, product management, and collaboration.
Peter:Visit humanizing work.com to learn more about our workshops, coaching and our online courses, or to bring us in to support your team.
Richard: And if you get value from this show, we’d appreciate it if you would help other people who’d benefit from it find the show. And on YouTube, the best way to do that is subscribe, like the episode, click the bell icon, drop a comment.
Richard:And if you’re listening to the podcast, there is nothing like a five star review to make a huge difference in other people finding the show.
Peter: Okay. If Richard and I were only gonna adopt one piece of Scrum, it would be the retrospective.
Richard: Really? I thought you were gonna assign me to Scrum master and you were gonna be the product owner.
Richard:We’d make chat. GPT do all the work?
Peter: Right! The job of the retrospective is to build a habit of regular team improvement, and no matter the kind of work you do or the size of your team, taking some time every week or two to ask how to work more effectively is a good idea.
Peter:You don’t even need to be working in sprints to benefit from retrospectives. Just put a recurring meeting on a calendar to reflect on how the team does its work, and pick an improvement to experiment with. Some teams skip the retro retrospective and focus on continuous improvements. Others do monthly kaizen sessions.
Peter:Using a retrospective gives you a regular cadence so it doesn’t fall off the agenda. And it connects you with the wealth of resources for how to do it well, including our online course on how to run better retrospectives, which we’ll drop into the show notes.
Richard: The next piece we’d add, if we were treating Scrum as a buffet and picking what was most useful would be the sprint review. In Scrum, the review does three jobs. It builds trust between the team and its stakeholders, provides regular motivation boost for teams who get to show off their work, and it acts as a feedback loop on an increment of whatever it is that you’re building.
Richard:Even if you’re not looking to get feedback that’ll change your plan, if you have a pretty good idea of what you’re doing, you can still help build trust and increase motivation with a regular progress update, an occasional demo or even just a status email highlighting what you’ve completed on our small team.
Richard:We do have a weekly review on Fridays to get out of the weeds and reflect on what we all accomplish that week, but most of our actual reviewing work happens throughout the week incrementally when something is ready for feedback.
Richard:The scheduled review helps us ensure that we step out of the day-to-day work. The just in time reviews get us quick feedback. That’s been a nice combination for us to get a lot of the benefits of a sprint review, but in a slightly different way.
Peter: Once you’re scheduling regular reviews, the next logical piece to add is a planning meeting. The job here is to focus the team on what’s next and surface dependencies related to that work, but it doesn’t need to be a long, detailed work breakdown where you assign every task and estimate each of those tasks.
Peter:Just ask the team to think ahead to the next review and decide what’s most likely to get done between now and then, or to put it slightly differently out of all the things we could do, what do we wanna focus on next? Ask if anyone needs help from teammates to get that work done. And once you’re aligned, the meeting can be over on our team.
Peter:We do a high level planning meeting on Monday of each week, and we don’t go into all the details. We focus on where we need to be aligned and where we’ll want to collaborate that week. It also gives us a chance to check in on how everyone’s doing and stay connected socially.
Richard: With those three pieces, you’ve got the start and end points of a sprint in place, but it’s not really a sprint, in the scrum sense, if you’re not trying to get some releaseable output during that time period, some product increment.
Richard:The jobs done by a sprint with a releasable increment are reducing technical and customer complexity and building trust. Adopting this approach has the benefit of being able to show finished things at the review, which builds more trust with stakeholders, increases motivation, and enables much better feedback.
Peter: And if we wanna plan just one or two weeks of work that could be finished in that amount of time, we’re gonna need to break the work down into thin slices of value and learning. And in order to keep track of all that, a product backlog becomes important.
Peter:The job of the product backlog is to make priorities transparent for the team and for stakeholders. You could start with just a minimum viable product backlog, one that only includes the next big outcome the team is working towards. You could then split that idea into thin slices using our feature mining and story splitting techniques so that you could get several of them done in a given sprint.
Peter:Our online course, 80 20 product backlog refinement, takes you from beginner to expert in those techniques. And again, we’ll drop a link to that in the show notes.
Richard: On our team, we don’t have a very long and detailed backlog. We have a lot of big things we want to accomplish over a longer period of time, but the detailed part of our backlog is quite short, and the goal is just to get things small enough so we can help work flow through the team.
Richard:So we have frequent opportunities to learn and add value, and we’re always looking for ways to help front load risk mitigation. We wanna prove something works by delivering a small slice of it.
Richard:The alternative here, breaking work down into tasks by specialties really only works when there’s little to no uncertainty in the work itself. If your team has that characteristic, it probably works to skip thin slices of value and just work on tasks and coordinate those.
Richard:But if you’re building something new for humans, if you’ve got dependencies outside your control, you’ll benefit from better slicing and focusing around value and learning.
Peter: Okay. As we build this up, at this point, we’ve got a product backlog with thin slices of value. We plan, we review, and we retrospect together, and we’re probably getting a high amount of value out of those pieces. Now, this all assumes that you’ve got a team that has the right people on it and they know what to work on, and the scrum roles provide some guidance on that.
Richard: For example, on on any team, someone or some group of people needs to decide what’s most important. Scrum calls that role product owner. Even if you don’t have somebody with that name on their role, you still need a clear process for resolving trade-offs and saying no to the wrong work. Someone to take the lead on creating those thin slices since slicing emerges new prioritization questions. If no one’s accountable for those outcomes, prioritization tends to become reactive and overly political.
Richard:Some teams might have an obvious individual who can do all this well and take it on. Others might choose to do product ownership more collectively. And as long as the team has a clear process for making prioritization decisions, it should work. We train product owners from basics through advanced product ownership, and you can check out our events page to find the next chance to sign up for a public course.
Peter: The other pieces of scrum, like a daily scrum, the sprint backlog, the definition of done, the scrum master and developer roles solve real problems too, like frequent coordination for the daily scrum, improving the quality of the, of the output with the definition of done and building and supporting the team for the Scrum master.
Peter:If you skip them, you’ll still need ways to solve those problems, whether that’s async updates, or tech leads stepping into servant leader roles, or shared team agreements. The Scrum solutions all add some value in different contexts. But notice at this level of the Scrum practices we’re getting into how the team does their day-to-day work.
Peter:You might use them and you might find other ways to get the same benefits without them.
Richard: Now we know as Scrum trainers that looking at Scrum this way might make some Scrum experts a little uneasy, and that’s fair. Scrum is a powerful system when it’s used holistically as it’s designed. But in our experience, many teams never get the chance to adopt all the pieces.
Richard:So our goal isn’t to redefine Scrum, it’s to explore what’s broadly useful from it and what you might be missing out on if you skip parts of it so that you can meet your team where they are and you can improve together.
Peter: We’re curious to hear how your team does these jobs, which Scrum practices have worked well for you, and where have you found better answers for your context. What parts would you consider most broadly applicable, and what parts have you tried and found you just didn’t need them?
Peter:Let us know in the comments and thanks for tuning in to this week’s episode of the Humanizing Work Show.
Last updated