Heed these core Scrum values to see measurable change

What makes the difference between good Scrum and bad Scrum? The Agile-rooted framework is not simply a nebulous measure of how well people collaborate, and it's definitely not a mechanized version of Waterfall. Instead, it segments roles and activities in ways that should improve software development.

Scrum is a framework for development processes. Teams that adhere to core Scrum values -- focus, openness, commitment, courage and respect -- see measurable efficiency benefits. Those teams understand the customer experience, keep scope in check and complete projects as quickly as possible.

Scrum's founders added these five values to The Scrum Guide in 2016:

• Focus. Prioritize work on a sprint, and work toward the team goals.
• Openness. Share information about the work, including challenges.
• Commitment. Adhere to and meet the goals that the team sets.
• Courage. Do the right thing, and directly address problems.
• Respect. Treat every team member as a capable and independent worker.

With bad Scrum, projects become mired in red tape -- multiple managers or product owners need to weigh in, committee meetings take up too much time, and developers lose sight of user needs.

"If you're going to go slow like that, then Scrum is just overhead," said Ryan Ripley, a professional Scrum master and trainer. "If you're not using Scrum to be opportunistic in the market, please stop. It's way too expensive to not take advantage of opportunities quickly."

Put simply, Scrum is pointless unless the team adheres to its basic principles consistently. Ripley sees commitment misinterpreted as adherence to scope, rather than a behavioral expectation, for example. It's difficult to be open with yourself and colleagues. And focus is under constant attack from new projects and initiatives, whether that added work contributes to the company's goals or not.

Ripley, along with co-author Todd Miller, wrote the book Fixing Your Scrum: Practical Solutions to Common Scrum Problems. The Scrum enthusiasts share their successes, failures and teachings across years of coaching Fortune 500 companies, lighting a path for organizations to follow.

In this podcast, Ripley explains some of the threats to core Scrum values, as well as other concepts detailed in the book. He covers the three essential Scrum roles: a single product owner, the Scrum master and the development team. When the three positions understand their responsibilities, Ripley says, the team achieves development and delivery excellence.

"It's almost like a peaceful balance of power, as long as people are staying within their boundaries," he said. When the subject of power dynamic between the roles pops up, Ripley bristles at the idea, as he considers it antithetical to the values Scrum promotes.

Scrum masters play a selfless role in this model. It's not enough to facilitate Scrum, as a Scrum master has to love their team, Ripley said. "[Love] is such a weird word to use in tech especially, but we mean it. It's that kind of care for the people that they're serving. You want these people to just do amazing things, and you have this drive, this passion to make sure that they have everything they need." The Scrum master also removes impediments that could prohibit the development team from finishing projects.

The right roles, and the right people to fulfill them, all revolve around the core Scrum values. If you can't abide by those behavioral characteristics, he says, you're destined to fail at Scrum.

"[Without those behaviors], we lose the ability to collaborate and work together well," he said. "I think a lot of teams and companies, they've left these values out. They're looking [to go from] step one to 1,000, without the behaviors that really support the processes. They get this mechanical version of their old Waterfall practices; they don't see true improvement; they're not competitive in the market. It just leads to frustration, and almost resentful work."

Ripley talked about why the daily Scrum is a way to measure the health of the Scrum team, and why it's essential to differentiate that meeting from the daily standup. He also discussed the value of sprint planning meetings, which are required in Scrum and can serve as a great opportunity to inform and motivate developers.

Editor's note: Ripley spoke with site editor David Carty and assistant site editor Ryan Black. The transcript has been lightly edited for clarity and brevity.

Ryan Black: I'll get things started here. First thing I wanted to ask you, Ryan, is for you to maybe quickly just run through what you consider to be the core Scrum values, and where you think there might be some confusion around those values -- generally where people tend to be the most confused from what you've seen.

Ryan Ripley: The core Scrum values -- I love that you're starting here, because I think these are misunderstood, and some of the most important pieces of the framework. The core Scrum values are focus, openness, commitment, courage and respect.

Focus [means] that people can actually focus on a goal and not be distracted, and they're given the opportunity to achieve it.

Openness being open to new ideas, open to experimentation, open to the fact that sometimes we're going to get it wrong, but also open that we ourselves are incorrect, right? So, I think that's really hard on teams -- when we say things, when we talk to people, when we're working with others, we generally believe that the things we say are true, but sometimes you're going to get proven wrong -- and being open to that.

Commitment is such a misunderstood Scrum value. Commitment is typically thought of as a commitment to scope. But, in Scrum, we never commit to scope. We commit to a sprint goal; we commit to one another to bring our best selves forward; we commit to being good stewards of the product owner's money; we commit to serving the customers in the best way that we know how, with a minimal but sufficient solution. So, commitment is really a behavior, not something about scope.

Courage, it's really difficult to say 'no' to people. But, if we don't say 'no,' we can't maintain focus, [and] we can't keep our commitments to our goals. That courage really gives us the opportunity to maintain some of our other values, but it also preserves transparency, which is so important to Scrum, right? Scrum was built on empiricism. We have to have transparent work, and if we can't have the courage to say what's actually happening and going on, man, we lose that ability to bring empiricism to the forefront as a competitive advantage. That courage, then, that is so essential.

Then, finally, we have respect for one another, respect for each other. Everything is a false flag if we cannot respectfully conduct our work.

Those values, they're behavioral. So we can do mechanical Scrum, we can follow the framework and try to create steps to product delivery nirvana, but without those behaviors, we lose a lot of the secret sauce for great teams. We lose the ability to collaborate and work together well. I think a lot of teams and companies, they've left these values out. They're looking [to go from] step one to 1,000, without the behaviors that really support the processes. They get this mechanical version of their old Waterfall practices; they don't see true improvement; they're not competitive in the market. It just leads to frustration, and almost resentful work. That's really why our book exists. We wrote Fixing Your Scrum because we saw this so many times. If you noticed, the book, the undercurrent, the undertone, the theme of that book is really 'bring the values forward, and things get better.' Hopefully, teams start doing that.

Black: Among those [five] behaviors and values you listed, what do you think teams or IT organizations fail to do the most often?

Ripley: Whether it's focus, openness, commitment, courage or respect, when you think about those in context, I find that focus is often completely lacking. We assign teams to four different projects. We have a portfolio of 1,000 things in flight right now. We have way too much width. We're not limiting our work in progress. We're amazingly good at starting things, but not good at stopping things. I think focus really falls flat most of the time, because we have to look busy to seem successful; we have to look busy because that's what we're measuring instead of value and some other things. I'd say focus gets lost.

I was recently in the Midwest -- well, I live in the Midwest, so it's not a shock that I was working with a company in the Midwest. [They said,] 'It's a grind, we're having a lot of trouble with our portfolio.' [I said,] 'Cool, let's take a look at it.' They had 150 projects in flight -- 150 projects for a medium-sized company in the Midwest, that's a lot of stuff going on at once. I said, 'What do you want to invest in this year?' Most companies had rocks or boulders or big goals; they had three or four of them, and we put them on a wall and said, 'That's cool. You've got four things you're trying to invest in. Let's map your whole portfolio to those four things.' Almost immediately, they came to me and said, 'Ryan, this project doesn't map anywhere.' I said, 'Cool, let's put it over here in this other area.' Out of 150 things that they were working on, that they were staying busy with, that they were trying to complete, about 50 of those things actually mapped to things that they wanted to invest in, things that were important to the company. About 100 projects were basically [keeping] people busy, and everyone was stunned. They're like, 'Why are we doing these things if they're not hitting our bottom line?' Some of it was keep-the-lights-on kind of stuff. So, we created a 'keep the lights on' bucket, and about 10 things floated over there. But the rest of that work was busy work, and [they said,] 'Well, what do we do now?' [I said,] 'Let's enhance focus and cut those things,' and people freaked. [They said,] 'What are these people going to work on, [who are] working on these other 90 projects?' [I said,] 'Let's ask them how they can best contribute to the 50 things that are most important.' Lo and behold, about two months later, I'm checking in, and 10 projects [are] finished. They're like, 'Ryan, we've never finished 10 things in a quarter like this. I was like, 'I know. Isn't focus amazing?'

When we lose that focus, when we're not actually driving towards things that are important, if we're trying to keep everyone 100% utilized and 'let's stay busy all the time,' man, [with] our companies and our organizations, the impediments build up and we're unable to get to 'done.' It's pretty wild. So I would say, for me, it's focus, but I'd imagine any other company you go to, you can find issues with openness, courage, commitment, respect. But, for me, focus is the one that I usually see right away.

Black: That makes a lot of sense. I have to imagine that probably, you go to any company, they're going to think, 'Oh, yeah, we have a project that sounds like that.' I did want to ask you about something else though. So, in your view, what should be the power dynamic between the product owner, Scrum master and the development team? Of course, Scrum is a very roles-focused framework. What checks and balances do you think should be in place between those roles?

Ripley: I think the framework actually puts the checks and balances in place beautifully already. I think when we look at the roles, and we figure out how they're supposed to be played and performed, these things shine through pretty well.

Let's think about the product owner first. The product owner owns value, right? They decide what we're going to work on. They set the product vision. They collaborate with a dev team, on what we're trying to build. They really own the 'what' and the 'why' of our work. Why are we building this thing? What is it that it's going to do? How is it going to best serve a customer? That value stream is really where they're at.

The development team, they just decide how best to do the work. They get to decide what quality means, they get to decide how to do their work -- within some constraints, right? The organization has rights to set some boundaries there. Management is still needed to help set boundaries around that. But for the most part, the dev team is deciding how best to do the work. There's a balance there, because that sounds like the dev team controls anything, but keep in mind, the product owner decides if they're going to fund that team. So, there's that balance there. Take it out of software for a minute. [Say] someone showed up at your house to build the deck. If you've hired them to put a deck on the back of your house [and] they showed up and started to build a gazebo, are you going to pay that invoice? Absolutely not, right? So it's the same kind of dynamic between a product owner and a dev team. So, we give a lot of control to the dev team -- and, make no mistake, Scrum is a developer play; Scrum is here to make developer lives better, right? So, the devs are deciding what work to pull into a sprint. They're deciding to how to deliver the best quality, they're making a ton of decisions about the work, the product owner is making a decision on whether or not to fund the next sprint. So, there is that dynamic balance.

As far as like the power dynamic, I wish we could throw all that language away. The dev team and the product owner have to be collaborative partners through the whole product development effort, right? These are not opposing groups. These are two roles that have to play beautifully together. They just have to get along. So, it's not a power dynamic. It's a collaborative working agreement, a working relationship, where the end goal is product.

The Scrum master doesn't own a lot. If I'm in a Scrum master role, I'm there to make sure Scrum is well understood and enacted. I'm there to make sure that there are changes going on within the organization that will make life easier for my Scrum team. I'm there to partner with the product owner and help desk to become an Agile product manager. I'm there to serve. As far as any power dynamic with the Scrum master, there's very few situations where I'm making direct decisions about anything, and it's usually related to Scrum. So, when you think about those three roles and actions together, you'll see it's more of a collaborative relationship with some boundaries, right? The Scrum master owns Scrum, the product owner has value, and they express value through a product backlog. The dev team owns delivery and quality, and they express that through creating the increment. Hopefully that long-winded answer helps, but it's almost like a peaceful balance of power, as long as people are staying within their boundaries. It's more collaborative, I would say. Collaboration is the word I would put when I think about the power dynamics between the roles.

David Carty: I think trust is a big part of that equation, right? I think that's something that a lot of organizations talk about, trying to engender trust. You talked about collaboration a little bit here, and also the boundaries. So, it's interesting, you have these boundaries, you encourage these different people to collaborate, and understand each other. And is that supposed to facilitate trust in a little bit more of a natural way? Or is it just something you continuously work toward over time?

Ripley: Trust is a weird and misunderstood thing. I think, for some reason, we understand it in our personal lives, but at work, we totally lose sight of it. Trust is on a spectrum, and trust is transactional. I think it's understanding those two things. I think it was actually Esther Derby who taught that to me, where trust is on this spectrum, right? When I'm building trust with teams, I try to remind them that, look, there's some things that your business partners won't trust you with, there's some things they will. We earn trust along that spectrum as we go. To give you an example, I've been married for 15 years to my great wife, and we trust each other with our secrets, our fears, our worries, our dreams, our aspirations -- but my wife will not trust me with laundry. I've wrecked too many sweaters over the years, [and she's] like, 'Please, just don't touch it.' Now, I've been accused of doing that on purpose, but I deny those allegations. But what I'm saying here is, they are very, very important things that she trusts me with, and there's other things that she doesn't.

So, I think it's the same with people in teams and organizations. We need to realize that we're on a spectrum, and we're earning our right up and down that spectrum, but trust is also transactional. We earn trust one transaction at a time, one deposit at a time. Unfortunately, it takes one bad moment to wipe out the whole account -- have you ever noticed that? It takes forever to build up trust, but it takes one bad moment, and you wipe all of it out. So, trust is interesting. Teams will say, 'All right, Ryan, that's a cool academic view of trust, but what you do?' And I go back to the development team; we build trust by delivering valuable things that the product owner expected and that customers need. If we can do that over and over and over, the product owner starts to trust the dev team. Then stakeholders start trusting the product owner. And there's this flow. The organization starts seeing profit, and then they start trusting this whole Scrum team as a unit to do smart things.

So, I think we earn trust, initially through delivery, but that really never ends. It takes that collaboration we just talked about by leveraging the Scrum values and using the framework correctly that you have the opportunity to deliver so that we build that trust incrementally over time. Does that make sense?

Black: Yeah, it sounds like, to take the laundry example you talked about before, it sounds like, in an IT setting, you could have a QA professional, who always does their work on time, is good at a great number of things, but everyone knows they're terrible at security testing. So, it's just like, you trust this person with a whole bunch of other stuff, but you just don't trust them to do security testing, assuming they're bad at it.

Ripley: Well, so I think it starts there. But as a Scrum team, though, and if we leverage the Scrum values, now we have our commitment to this person and some respect towards this person, let's pair them up with someone who is good at that security testing; let's level them up and give them a chance to show that they can actually do this. So, yeah, I totally agree with the example there, but then let's leverage the values, and change that behavior, and not leave distrust sitting in a team. Does that make sense? So those values help elevate -- as we know, trust is a fickle, kind of weird thing, but the values help us cultivate that, and build it and change it so that, as a team, we're actually growing and changing and learning. It's amazing how, if you leave this stuff out -- if you don't have the Scrum values in place, if you don't worry about the trust dynamics, because that will impact transparency quite a bit, if you leave all that out -- and you just try to do Scrum as a step-by-step framework, how much you lose from it. I mean, isn't that wild?

Carty: Right. To bring it back to Scrum masters, we hear about the concept of being a servant leader associated a lot with Scrum masters. Can you explain some of the characteristics of a good servant leader in that type of role?

Ripley: People ask me that a lot. They get really caught up on the servant-leader aspect of the role and they say, 'Ryan, how would you know that someone should fill that role? Or that they could fill that role?' I usually start with -- I have three rules, and we talk about this in the book quite a bit. But it's really three things.

First of all, a person has to love their team. That's such a weird word to use in tech especially, but we mean it. It's that kind of care for the people that they're serving. You want these people to just do amazing things, and you have this drive, this passion to make sure that they have everything they need.

The second thing is that you have to want these people to be wildly successful. So, as a Scrum master, I think one of the hardest aspects of this role is that nothing is about you. You are there to serve others. I'm there to get other people promoted. I want my product owner to be so wildly successful that they get promoted to new heights and new levels. They get new levels of influence. They get new levels of control over the product. I'm honestly fighting to get another person promoted, right? I want these people to be wildly successful.

And the third thing is, I have to have zero tolerance for anything that's getting in their way. So I have to go into the organization and work respectfully as a change agent to get these impediments, and blockers, and all these processes and practices that are slowing the team down resolved and corrected. I'm partnering with management; I'm partnering with leadership. I'm out in the world and talking to HR about hiring practices. I'm working with finance about, 'Hey, this annual budget cycle really kills us because we have these new opportunities where we know we have to spend six months to find the cash. Can we do some drip finding? Can we do some experimentation?' I'm out there working so that there's nothing getting in the way of this team.

So, if you have someone who can do those three things, you have a servant leader. If you take these ideas further, that servant leader is being measured by how everyone else around them is progressing and growing and thriving. This is not a positional authority kind of thing. This is not a [situation where] only VPs can be servant leaders. A Scrum master [has] no positional authority over the team, the Scrum master cannot hire or fire, they cannot tell these people what to do. But what they can do is inspire them to new heights, and they can just serve them so that they can actually have a shot at reaching those heights.

Carty: Yeah, when you say, 'love your team,' it's such an interesting idea, right? Because, on the business side, you might have people that are a little bit more cutthroat. And IT, you know, stereotypically maybe has some more introverted types of people. So you describe how valuable that Scrum master role can be. And it's a combination of being both outgoing and selfless, in terms of how you describe it.

Ripley: Oh, I totally agree. Even this idea of the cutthroat business -- if we're building truly cross-functional teams, which are kind of the motor or the engine of Scrum -- cross-functional, self-organizing teams drive progress. There's no more business versus IT. Business people and IT people and any activity needed to deliver product, they're going to be on our team. So, there's no more us versus them, cutthroat versus introverted. We're all deciding that the same people that signed HR's and legal's and marketing's paycheck also sign IT's paycheck. So, let's just work together, and not against one another, to deliver a product collaboratively in a self-organizing way as a cross-functional team. Hopefully some of those behaviors disappear too, because it's hard to turn to your teammates and say, 'I'm against you,' when we're both heads-down, trying to deliver the same thing, right?

Black: In your book, Fixing Your Scrum, you caution teams against having multiple product owners per product, or a part-time product owner. But, let's say a team has a single dedicated product owner. in that circumstance, what are some of the most common ways in which a product owner tends to fall short in their responsibilities? Because, of course, if you have just one person as the owner of value in a team, that's a lot of responsibility. And if they fail to meet that responsibility, there seems like there could be a lot of repercussions to that.

Ripley: So, this was an interesting chapter to write. Basically, the product owner chapter in our book is about all the ways that these product owners can fall short. It's really hard. This is a big role. First and foremost, it's a massive role that we're asking people to fulfill. So being aware of that, like a Scrum master being aware of when a product owner is underwater, I think is one of the best remedies.

But when these product owners fall short, sometimes they disappear. Sometimes we find that these product owners are really fascinated by working with the customers and stakeholders, and they spend a lot of time in the field, but not a lot of time collaborating with the dev team. They tend to think that, 'Well, I've given my requirements. I've shipped them over the wall. I should be all set.' And, no, this is a collaborative working relationship between the product owner and the dev team. So, when this product owner disappears, there's this product ownership, this product management vacuum. So, I'll let you guys guess who fills that vacuum? Who fills that void when the product owner disappears?

Carty: The Scrum master?

Ripley: Sometimes. Yeah, so the Scrum master might step in out of pity for the team and say, 'All right, work on this,' which would be totally out of line for the Scrum master role. So, Scrum masters, if you're doing that, stop.

But it's typically the dev team that would step in and say, 'Well, we think this will work. This is what's on the card. This is what we talked about three months ago, so let's go ahead and fill that void, because we cannot get time with the product owner.' So, we get to sprint review, and, guess what? The stakeholders see this product that the devs think is really cool, but it's not aligned to their needs, and it's usually a disaster, right? So, we see that fail over and over and over.

We also see product ownership by committee. So, to the premise of your question, we recommend not having these groups of product owners. Well, guess what happens when you have five different product owners on a product, and they all have different areas of the product, they're all incentivized by the revenue on their product? You get gridlock. Or, if you have product ownership by committee, well now we have to manage the consensus, and we get a watered-down product, and it takes 10 times the amount of time it should to get a decision made.

So, we run into all these weird antipatterns, and a lot of what it comes down to is, we're supposed to use Scrum to be competitive in the world. We're supposed to use Scrum to have this competitive advantage to be opportunistic in the market, but if we're waiting forever for decisions, whether it's an absent product owner [or] product ownership by committee or multiple product owners, other people can outrun us. If other companies have one empowered person who can make the call about the strategy, the tactics or the budget around the product, and they can make it immediately, they can go faster than these larger organizations who require management through consensus, multiple committee meetings, one person decides on budget, one person decides strategy, another person is tactical. It's just slow. If you're going to go slow like that, then Scrum is just overhead. If you're not using Scrum to be opportunistic in the market, please stop. It's way too expensive to not take advantage of opportunities quickly.

So, a single product owner who has full control over the product, who owns the value-making decisions, that's the preferred method, because that is how we move quickly. Does that make sense?

Carty: Yeah, definitely. In your chapter, Reclaiming the Daily Scrum, you write about how daily Scrum meetings are, 'the subject of endless misunderstanding,' and also, 'one of the most reliable indicators of the health of the Scrum team.' That's putting some high stakes on these meetings. There are a lot of reasons why the daily Scrum can quickly become ineffective -- too many voices, not enough time -- you cover a lot of these in the book. What are some of the key objectives teams should aim for with the daily Scrum? What should they get out of it?

Ripley: I think the daily Scrum at its core is about figuring out how we as a development team are going to collaborate and work together during the next 24 hours to make progress toward our sprint board. And that's really it. Really, in essence, it's a 15-minute self-organization event for the dev team to figure out, 'Alright, I'm stuck on testing. So, who's going to help me? I know that this other group over here, these two devs are working on this feature ….' They're figuring out the blocking and tackling [fundamental tasks and roles] for the day, that's it.

So, it's not a problem-solving session. It's not a status meeting. It's not a Q&A with the product owner. It is just, how are we going to work together? How are we going to pair up, or mob, or test, or whatever it is we need to do today to make sure we're making progress toward our sprint goal, so that by the end of the sprint, we have the best possible chance of having a high-quality potentially releasable increment of products? And, that's it. Seems simple, right?

Carty: You would think so, but evidently a lot of organizations struggle with that.

Ripley: Well, it gets conflated with a few different things, right? The daily Scrum, people will call it the daily standup. A standup is a status meeting. It comes from past project management practice, and not changing the terminology to daily Scrum, I think, is dangerous.

So, it turns into this daily status meeting -- and, look, the product owner can go to a daily Scrum, they just need to stay quiet. If they want to listen in on what's happening with their product, that's great, but please don't participate. Far too often, the product owner might show up to a daily standup, they might start asking questions, the dev team might start asking product-related things. Suddenly this 15-minute, focused event that's basically focused on self-organization and collaboration sprawls down into this 45-minute jumbled mess of a meeting that no one really wants to attend.

I think focus [is needed] here: focus as a Scrum value. When we lose the Scrum values, we lose focus, that's when daily Scrums go bad. So, let's focus on what we're trying to do here. Are we making progress on our sprint goal: yes or no? Is our sprint backlog in good shape? Does it need to be refined because we learned something: yes or no? All right, let's break in 15 minutes. Look, if you need to go talk to the product owner because you learned something in the daily Scrum, go do that -- that's totally allowed. But, for those 15 minutes, focus.

I think the other thing teams need to do, and we recommend this in the book pretty heavily, throughout, is ask the three questions. So the three questions:

• What did you do yesterday to make progress toward the sprint goal?
• What are you going to do today to make progress toward the sprint goal?
• Are there any impediments to achieving the sprint goal?

Those have always been guidance. I'm glad that that's starting to get more explicit. I know during the last Scrum guide release in 2017, Ken Schwaber [chairman, founder and co-creator of Scrum] was adamant that these were always guidance and not required, but I think if you follow those questions in a legalistic way, it's very easy for your daily Scrum to kind of spiral into this daily standup status kind of thing. So, don't use the questions, walk the boards, you know? If you're using Jira, project it on a wall. You're using a physical board, walk the work, and just talk about, 'How do we move these things further? Is there anything that seems stuck?' Use those kinds of questions to figure out how we need to work together today to move the work closer to done.

Black: To ask about another kind of meeting in the Scrum framework. In your opinion, what should the ideal planning meeting for a sprint look like? Similarly, I have to imagine you'll probably say focus is a fundamental component of those meetings. But what are some things that must absolutely be discussed in a planning meeting?

Ripley: In a sprint planning event, we are taking a look at the current product backlog that hopefully has all the latest updates during the last sprint review. We're taking a look at all this great information that's ordered by value by the product owner, and we're all coming together as a Scrum team. We've probably invited some outside experts too. So I expect a self-organizing Scrum team to realize that we need a security expert for this next sprint, so they invite that expert. For all these shared services, bring them in, let's have the conversation.

We're going to talk about: What are the things that are important for this next sprint? What do the customers need most? What's the highest value thing we can work on? That discussion is going to take place, and eventually the development team is going to start pulling product backlog items from the product backlog into our sprint backlog. They're going to try to forecast out the work they think they could get to done, which is a high-quality potentially releasable product by the end of a sprint.

So, as they start pulling work in, hopefully they've already gone through refinements. Hopefully this work is small, discrete, well understood. Transparency does not mean visible; it means well understood. So, we've talked about this work before. We've done some diagramming, we've done some whiteboarding, we talked to our architecture teams, we understand how we're going to do some of this, and we start pulling those items into a sprint backlog. At some point, someone, hopefully on the dev team says, 'Well, wait a minute, this is probably more than enough work. This is a good forecast.'

Then they start breaking down this work. They first decided what they're going to do in a sprint, right? But then they're going to decide how best to get started. With some of these items they've pulled into their sprint backlog, they're also going to create a plan for what the work could look like. So [that means] some tasking, some more whiteboarding, maybe even some acceptance criteria we're going to use to know that we're done. All these things [they] are going to start actually talking through as well, and get that captured.

So, really, the sprint planning session is about creating a sprint backlog that also includes a plan on how to get started for the work. Now you're not planning the whole sprint, because we're going to learn -- and basically it's like as Woody Zuill always says, 'It is through doing the work that we learn about the work we need to do.' So we're not trying to plan the whole sprint. We're going to plan the first two or three days, so that we can figure out how to get started. Through doing the work, we're going to continue to update our sprint backlog, and our progress toward that daily sprint goal every day in that daily Scrum, which we talked about.

So, by the end of sprint planning, we should have that sprint backlog in place, but we should also have a sprint goal. What is the goal of this sprint? The sprint goal gets so horribly misunderstood -- it's tragic, because, first of all, sprint goals are required in Scrum, and there's so many teams who don't use them. This sprint goal really gives us this outcome-driven goal, right? The sprint goal should be a connection back to customer. Through the sprint goal, the dev team should know how they're empowering people to do something new, how they're changing the world, how they're helping a customer solve a problem, right? We're connecting them to the 'why' of the work, which keeps a dev team motivated. If you want to demotivate a dev team, don't let them see how they impact customer. So set the sprint goal once we understand the kind of work we're going to pull in. Once that sprint goal is in place, this outcome-driven, customer-facing thing, we're probably ready to get started with the sprint. But keep in mind, people get hung up on the sprint goal idea, [so] I want to make sure it's clear, if we have five things in our sprint backlog, all five things do not have to relate to the sprint goal. You can have one or two things that are tied directly to the sprint goal, and some other things that aren't, but you better make sure that those two things tied to the sprint goal get to done, or at least you're keeping an eye on them to make sure the sprint goal stays intact.

Once we get to the end, we've got a sprint goal, we have the sprint backlog, the product owner and the dev team have collaborated on this, they're in agreement on the work that needs to be done, we get started on the sprint. Does that help? Does that make sense?

Black: It does.

Carty: Yeah, definitely. Ryan, I'm sure we could get you talking about Scrum all day long. I have no doubt about that, but I'll be respectful of your time, and that seems like a good spot to stop. Congratulations on the book, and thank you for talking with us.

Ripley: Guys, I really appreciate it. Todd and I, we both have been working, or thinking about, or trying to do Scrum in different ways for the past 20 years. We've spent the last two years with Fixing Your Scrum, just putting in everything we've learned, everything we've tried, all of our failure stories, all of our mistakes, all of our wins. We hope that people read it, and they start to get passionate, and they start talking about Scrum like we have, as this empowering framework, not something that they have to do. So, hopefully people check out the book, it's [called] Fixing Your Scrum: Practical Solutions to Common Scrum Problems. It's available on Amazon in paperback, it's at PragProg.com in digital. And we just hope that people use this book to do better Scrum. If they do that, hopefully then Todd and I will be happy, and hopefully some dev teams will be happy as well.