The Scrum Framework

In this episode, Dermot Ryan and I unpack Scrum and give you an overview of the entire framework. You'll find show notes for this episode at https://AmazingApps.Show/2. 

Let's go. 

I'm your co-host Neil Benson. And this is Dermot Ryan. In this episode, we're going to give you a short overview of this com framework from start to finish.

We'll start with the sprint, this com events and then cover roles, artifacts, and the scrum theory. Dermot, why don't you take it away with describing what a sprint. Great. So a sprint is a time-box event of one month or less during which had done increment is produced. And what do we mean by don't increment?

Well, by that, what we mean is that it's usable and potentially releasable. So at the end of a sprint, which is usually 1, 2, 3 or four weeks in length, We need to be producing something that can be released to production as sprint has four events, which we'll talk about later on. And in those events, we do all the dev work to produce that Don increment, a sprint should be other consistent duration.

And what we mean by that is that if you decide on a sprint length to be say, two weeks, The duration of your project, you should stick with two weeks sprints throughout the project. So you could think of a sprint really as a mini project, no more than four weeks in length when it gets longer than that, the definition of what might need to be built may change over that time.

And complexity may arise and you might introduce risk. So it's best to stick to four weeks or less. And that's what the scrum guide recommends. So essentially that's what a sprint. But in your Microsoft dynamics, 365 projects, what have you find to be the best sprint length you've set up to four weeks?

Are yours normally four weeks long? Is that. No early in my career, we trialed two weeks. And, but we found with feedback from the product owners, which is a role we get into later as well, that three weeks was better. And the dev team felt that three weeks was better as well. Now, the reason for that was by the time you get through, we call it a mini project.

So if you want to be releasing at the end of every sprint, we found two weeks was too short to get our done increment. And we found a four weeks was too long. So three weeks was the sweet spot and I've done that in a few, 365 projects in three weeks seems to be a really good lamp. Do you want to take us through the other four events in each.

Sure. So within a sprint, you have the four events as defined in the scrum guide and they are called from the top. The daily scrum also called the stand-up. You have sprint planning, sprint review and sprint retrospective. So I'll go through each of those one by one, the daily scrum that lasts for 15 minutes and it's usually every morning and it's at the same time, same place every day.

This is. Dave team plan to work for the next 24 hours so that everyone gets together. Do you usually look at the scrum board if you have one and we use this process to inspect the progress towards our sprinkle three questions, get addressed at the standup, and that is what did we work on yesterday? What are we going to work on today to take us to our sprinkle?

And what are the blockers or impediments to prevent us from achieving that spring? It's not to be seen as a status report. This is where the team, the dev team get together and they discuss the issues toward the sprinkle and they overcome the impediments and the blockers. The scrum master ensures that this meeting is held, but the meeting is far to devs.

Other people can attend such as product owners, VA's observers, but they should be seen as observers. This is the dev team who want this meeting. So that's the daily standup, and that has to be timeboxed to 15 minutes. It should not go longer than 15 minutes. The next event that we have is called the sprint planning meeting.

This is where the work to be performed in a sprint is planned by the entire scrum team. So not just the developers, but also the product owners and the BAS and everyone in the scrum team. So this is time box to a maximum of eight hours for one more. So, if you're doing less than one month sprints, then you prorated that back.

So for us, we do three week sprints and we do planning for six hours. Planning is broken up into two parts. First part is what will be delivered here. The product owner discusses the objective of the sprint and what product backlog items they would like to include. But only the dev team can select the product backlog items to commit to the sprint that's in the first part, and also here in the first part, the product owner teases out with the dev team, what the sprint goal is going to be.

So the whole scrum team is involved in this discussion and we tease out what it is we want to achieve. Normally on my projects, we take a break at this time, cause that's, this goes for an hour or more. And then we come back later on and part two of the sprint planning session is how are we going to do the work to deliver what we discussed?

So sometimes this can just be the dev team on their own. Sometimes the product owners may contribute on the projects I'm involved in. We have the product owner nearby if we need them, but the dev team themselves, they discussed the work, how they're going to do with how they're going to deliver the increment.

That's the standup and that sprint planning. You said though that the sprint planning, the dev team selects the items they're going to work on in this one. That seems a little backwards. Isn't it? The product owner who sets the priorities and tells the team what to deliver and what they need done in that space, the product owner can suggest this is the list of product backlog items, which are prioritized by value naked suggests saying, this is what I would like to achieve in this sprint.

I have the goal in mind, collectively the team will decide on the goal and with that goal for the sprint. Then the dev teams select the items to commit to what's called the sprint backlog and how best to achieve that goal. Of course, this isn't done completely blind. They speak to the product owner. It's a discussion in this meeting and then the dev team select the product backlog items after product X.

Which the product owner has prepared. Then when they go to part two, they can do high-level estimates to decide how much capacity they have in sprint to be able to do these items, how they're going to do them. And then later on in my projects, we usually go back to the product owner at the end and say, okay, we think in this sprint, we can achieve this many product backlog items and there's a little bit more horse trading.

And then you decide finalize on the sprint backlog. That's the sprint planning. The next event we have is the sprint review. And this is four hours for a one-on-one sprint. And that can be prorated less for sprints of shorter duration. So for three weeks sprint, you would have three hour sprint review meeting.

The purpose of the sprint review is to inspect the increments and adapt the product backlog if necessary. So the people who are there at this meeting, you'll have all the scrum team and any stakeholders that want to collaborate about what was done in the sprint, and then collaborate on the next things that they would like to do and to optimize the value of the product backlog item.

If you remember earlier on, we mentioned what a done increment is. So just to remind everyone a done increment is what was completed within the sprint has to be usable and potentially releasable. It doesn't have to be released, but it should be potentially releasable at the end of the year. The product owner will start off by explaining what was done in sprint.

And then the dev team will illustrate that by showing to everybody how it functioned and what was done, everyone, including the stakeholders can collaborate on what needs to be done for the next sprint coming up and provide input for sprint planning. Review the timeline, the budget anticipated releases.

So the result of the sprint review is a revised product backlog that defines the probable product backlog items that are going to come up in the next sprint and also illustrate everything that was built. That's the sprint review. It's the next one we have is the sprint retrospective, which is the very last event in a second.

In the sprint retrospective, the scrum master ensures that it's positive and constructive. And it's a scenario where the scrum teams get together and they review the processes of what they did in this sprint just finished. So it's not a blame game. It's not about pointing fingers at people. It's about inspecting.

Which goes to the core of Scrum. So we inspect what we did, what processes we use to build the done increment and how can we improve going forward? This is another timebox event at most three hours for one month sprint. It occurs after the sprint review. Typically on the very last day, we usually ask three questions at this.

The format is what did we do? Well, what didn't we do so well? And what actions can we take going forward to improve the process? And the big role of a scrum master here is as well as facilitating they can contribute, but the need to ensure that it doesn't degenerate into a blame game. This is about inspecting the process and adapting it so we can improve going forward there to for Scrum events, snail.

So just from the top again, they were to stand up the sprint planning, the sprint review and sprint retrospective soaping, Neil, you might be able to take us through what the sure. Thanks, Tara. So there's three roles within a Scrum. There their product on there, the dev team and the scrum master. So the scrum team is all of those combined, starting with a product owner.

That's really the person responsible for maximizing the value of the product in my Microsoft dynamics, 365 projects. That's quite often the clients senior stakeholder on the project. It's best if that's one person, rather than a couple of people are a committee, because we want one person who's going to be accountable and responsible.

We can have that person supported if we want. Business analyst, some of our tests on list, but we just need one person to be the product owner. Ideally, that person is senior enough to make all the decisions there are available enough to spend time in the project team. And they've got the authority and the vision for Microsoft dynamics, 365, finding that person can be really challenging, especially finding somebody who's available enough, which is quite often why.

Then we have people like business analysts supporting them. Neil is the product owner a full-time job on a scrum team, or can they do another job? I find that the best product owners are almost available full time. So it's easily a three day a week job in order to answer the team's questions, refining the product backlog items.

I review the work that's been done and participate in all those Chrome events. Some of my best product owners have also had a day job, but that's been a really tough one. And they ended up not being available as much as we'd like, and they need to be the people who make the decisions. So therefore they would need to be available.

Is that a fair. Statement. Yeah. I've seen a couple of projects where they delegate that decision down to somebody else. And then second, guess those decisions when it comes to the sprint review, whenever they see the output of the team's work and it wasn't quite what they had in mind. So really helps if they're there on a almost full-time basis.

The next role within this com team is the dev team, which is all the developers on the team. You don't have to be a Microsoft dynamics, 365, you know, dot net developer to be a Scrum developer. It just means anybody who's contributing towards the work. Completing the product. They do the work of delivering the potentially releasable product increment at the end of each sprint on the cross functional, which is a really important concept to get your head around.

That doesn't mean that everybody on the team has to have all of the skills. That means that as a whole, the team has all the skills in order to do all of the work. I find that very occasionally we have to bring in an outside person, who's maybe got a specialist skill in user interface, design, or happens to know the back office system that we need to integrate.

But really 99% of the work should be completable completable. If that's a real word by that. But the dev team, we don't use any titles. There's no lead developers. There's an architects, everybody's a developer. We're all contributing to all the stories. Another important facet of the dev team is that it's self-organizing, we don't really need a manager or a leader.

And that dev team, they should be as a group, making the decisions about how to tweak their processes and how to complete their work. They might seek some guidance from the scrum master. They seek some clarity from the product owner, but they're not a team that looks to a project manager to assign work to them.

They figure it out themselves, which is a really important, I don't fray liberating way of working. I find together they're accountable as a team. We're all coming together as a team to get the work done. We're not looking at individuals and measuring for example, individual productivity. Great. And what's the typical size of a dev team?

Neil. I've worked in some pretty small ones. I think, you know, I've, I've worked where there's maybe just one or two of us in a dev team. Scrum Guide says that that's probably a little bit small. You're probably not big enough to be cross-functional, which is probably true. Three to nine members is kind of ideal three.

You probably have all the skills to do all the work nine. You know, that's the limit of the number of people you want involved in your team, because beyond that communication breaks down and it's hard for them to know where we're at and to gain consensus and those kinds of things. So three to nine people, I think is ideal question.

I get asked all the time about dev teams. Nail is where's the test or where's your BA where's your call? Can you talk a bit, maybe about titles and a dev team who are these people who are in the desk? So within the, within the sprint, we're completing all of the work to analyze design develop test. Yeah.

Release are done increment. So the team's got to share all of those responsibilities. So I might be doing a little bit of design work on one of the product backlog items. I might be configuring dynamics 365 for another. I might be either doing a peer review or some unit testing on somebody else's work.

So I'm really doing all of that work within the time box of the sprint itself. There's no roles, I'm not the tester. I'm not the analyst I'm contributing towards any of the work that I do. So that's the type team and the product owner nail that you want to tell us some more maybe about what a scrum master is and what their roles and responsibilities.

Sure. So I have no idea if Ken's Webber and Jeff Sutherland have ever watched a game of rugby in their lives. I don't know where they got the title, scrum master. It's not, it's not the player who passes the ball into the Scrum, slightly strange title, but the scrum masters got a couple of responsibilities, their responsibility to the team to coach them on the scrum process to help them facilitate some of the Scrum events.

Where they're invited to do that. They're also coaching the product owner on hi to maximize the value of the team. Hi, to refine a product backlog and make sure it's well prioritized and on the items within it are. Well-described also coaching the organization as a whole and how to adopt scrums. That's quite often working outside the scrum team, working with other scrum teams to share best practices and big differences that they're not a project manager.

They're not there to manage the budgets, to manage risks, to look after resources and to assign work to them. People on the team. That's not their role at all. So it's really about facilitation guiding. Best scrum masters that I've worked with act as like servant leader, they're there to support and enhance the team's capability and productivity, but they're not there to drive them along the way.

Quite often, they're asked to facilitate the scrum events. You talked about the daily standup earlier, where the scrum master can attend. They don't need to be there. It's not a status report to the scrum master, but quite often, they're there to keep the process moving along. They're there to protect the team from outside distractions and influence and shield them from anybody who tries to distract them, to borrow them for another project.

For example, I've seen that happen quite a bit. They're coaching the dev team to be self-organizing making sure the cross-functional and trying to remove any impediments. So things like getting access to systems, access to auto resources when that's necessary. Good scrum masters will go away and try and make that stuff happen in time for the team to not get blocked.

Okay. You mentioned there, Neil, that the scrum master is a servant leader to the team. Does that mean that they do everything for the team or is it more in a coaching and facilitating role? Um, I think rather than make cups of coffee for the team, it's their job to remember who's Rhonda is, that's what we mean by a servant leader.

They're there to support the team to show the leadership because there should be an experienced Scrum practices. But without telling people what to do, asking grit, coaching questions in order to have the team and breast Scrum, understand it and be able to apply it within their project. Dermot, there's a couple of artifacts that are described within the scrum framework.

You want to describe those to us and tell us how you've used those in your dynamics? 365. So the artifacts would like to speak about Neil. One is the product backlog, and we have another artifact that's known as the sprint backlog. And finally, then you have what's called the product increment. So I'll start with the product backlog.

Now, this is an ordered list of everything that is known to be needed in the product, whatever you're building, it evolves over time. The requirements come in with the BAS the product owners and the dev team would gradually build up your requirements. And collectively all those requirements become known as the product backlog.

They must have a. They get ordered by the product owner. They need to be estimated and the need to have a value number value. We mean what the value is to the business. Typically this is the product owner who has responsibility for this. So the product owner needs to order product backlog by value. So the most valuable items are at the top with the lower value items.

Further down, multiple scrum teams can work on more on one product backlog. So you can have what's called scaling up to a scrum of scrums, which we'll get into in another product. Within the sprint we have also what's called product backlog refinement. Now the scrum guide only says that the backlog should be refined, but it doesn't tell you how they should be done.

Typically in the projects I've worked with is when the dev team gets together with the product owner or their proxies to BAS and add detail to the product backlog items add, might add in high level estimate, and they help the product owners to order to product backlog. The scrum team defines how and when product backlog, refinements.

Uh, it should not take more than 10% of the dev team's capacity. And the dev team is responsible for all the estimates. Now this last point is one that people find hard to understand. Sometimes we get product owners or BAS telling the dev team, or this is going to take one or two days of effort in Scrum.

The dev team, the people responsible for doing the work are the people who are responsible for the estimates. So only the dev team should create the estimates. So that's a very important point with the product. The sprint backlog then is a subset of the product backlog. So this is where in sprint planning, we select all the product backlog items that we'd like to include in this sprint.

If you think of the product backlog as a big, long list of all the items to do for the product over the lifespan of the product. And then the sprint back dog is just a subset of that. It's a set of PBS product backlog items selected for the sprint plus a plan for delivering that increment and realizing the sprint goal.

If you remember back to earlier in the podcast, we mentioned that the sprint goal gets defined during the sprint planning meeting, the dev team owned the sprint backlog and only the dev team can modify a trout to sprint. So that's what we call the sprint backlog, the product. This is what is gets released at the end is potentially releasable at the end of the sprint.

This is the sprint backlog items that meet a state of done. And by done, we mean that it is complete. It has passed all its testing and it's potentially releasable does that have to be released, but has to be in a state that it can be really. Collectively all the sprint backlog items that have reached a state have done, they get called the product increment.

But you said that during the sprint backlog, it's kind of locked on the product owner can change the contents of it, but I thought we were agile. We could change the requirements at any time that doesn't sound very agile. If the product owner can change the priorities. So it's a good question, Neil. Uh, we are agile, but what we find is that if the product owner is allowed change to spend back.

That, what will happen is that the dev team lose their cadence. They lose sight of the sprinkle. Sprinkle is now changed. If the product owners changing what's coming into the sprint backlog, overall, that increment is at risk of not achieving the sprint goal. If the product owner keeps changing, what is in it, it's very important that only the dev team on the sprint backlog, when the sprint backlog is defined in the sprint planning, meeting the product owners involved, if they need changes, they will need to create.

Product backlog item. And that will be addressed in the next sprint or subsequent sprints, depending on the value of that product backlog item, a product owners can cancel a sprint. And the reason why they would cancel a sprint is if the sprint goal became obsolete. So if that business need was no longer valid, then the product order could say, well, there's no point completing all these product backlog items or user stories.

Let's just close this sprint. Let's cancel it and start over. The product owner can make that call. But while the sprint is running only the dev team modify to sprint backlog. I've had to cancel only one or two sprints in my entire career using scrum where something major happened to shift the direction of the business, which had a knock on effect on our project and the product owner wanted to determine it.

Particular sprint that we were in and going in a slightly different direction. So it was a pretty serious thing to do. Yeah. It's only happened to me once, actually in four week sprint, we were three weeks in and for same reason, the business needs changed and they decided they didn't need that goal that we were striving to complete and a sprint got canceled.

So, so Derma, let me, um, let me just wrap up maybe with a quick overview of the scrum theory. I think this is really important, particularly if you're new to school. You can understand the events, the roles and the artifacts, and still not really get Scrum. It's something, the theory is something you have to internalize once you really understand it and embrace it.

I think it really amplifies the knowledge. You've just gained about all the roles, the events and the artifacts. So the first thing to understand is something called the empirical process control theory, which is a rather grand title. And all it really means is we don't know how to produce the working software.

We don't know what the requirements are upfront. So we've got different inputs in every sprint, different sets of requirement. And the process that we're using, we'll have to shift and adapt in order to produce a good output at the end. So it's not like making big beans in a factory where, you know, the recipe for the sauce, you know, how many beans go in, you know, how to label the tin of beans at the end, that's a defined process.

The empirical process is you need to be able to inspect what's going in, inspect the product of the other end and adopt your product. To adjust your output. So that's in parasitism. That's the empirical process control through not really underpins the, the core pillars of Scrum, which are transparency, inspection and adaptation.

So transparency is a really important quality for the project team to all-in breasts. That's why we have our product backlog visible to the entire organization. It's why we invite everybody to come along to our scrum events so they can see where the project is that we don't need to do a lot of status reports because we've got complete transparency, the whole.

Inspection and adaptation underpins all of those four Scrum events that we've seen a daily stand ups to inspect our daily work. We have the sprint review to inspect the quality of the product at the end of the sprint. And we have the sprint retrospective to inspect an adopter process as well. Those two pillars underpin all the scrum teams.

And then there's a couple of characteristics. I think the common team as a whole need to adopt and embrace as well. Those are the principles of scrum, thankfully commitment, which I think is about it's the product owner committing to the sprint so that they're not going to change the requirements. It's the team coming back to the product or, and saying, yep, this is the product backlog items that we've taken into this sprint backlog.

We're going to commit and get them done by the end of the week. And it's about the team, all committing to each other, making sure they're not getting distracted. And that plays into some of the other, um, Scrum principles as well. Having courage, being bold, being not afraid to take feedback from users, not afraid to feel either, but when we do, we try and fail fast within the course of a sprint and learn from it and move on and we're focused.

Try not to get distracted by our last project or doing business as usual support work. We're trying to focus our time on this project. Under the work at hand fourth one is openness, which is pretty hard to practice. Sometimes. If you've come from a waterfall background where there's a lot of pressure to deliver within the, the phase, somebody else has estimated the amount of effort your task is going to take and you keep closed.

If you're think you're going to deliver late. In scrum, we're trying to maintain openness. So we don't have to wait until the daily standup to ask for help or let the team know that you're struggling with a particular problem. And then the last one is respect. This is about treating all the other team members as, as professionals, understanding that they're trying to bring their best ideas to work and embracing their ideas and their contributions and understanding that everybody's trying to make a real positive contribution to the team.

If we do that, then we offer respectful or another. We have transparency adaptation. Commitment, courage, focus, openness and respect. Those are the underpinnings of the Scrum theory. Derma nails seems like there's a lot of soft skills here, which surprises a lot of people. They think that, especially in it, if you go on to learn, say a computer language, then you can apply that to your role.

But here there are a lot of people's skills involved. It's definitely a different way of working. There's an intensity. That comes with everybody often working in the same room for a long sustained period of time. Uh, working together as a large team, you've got a client stakeholders working on the same product, the same time as consultants.

Team members as well. That's really a hallmark of the way that we conduct our Microsoft dynamics, 365 projects. And you'll find that those soft skills are really needed to deliver quality work in a very sustainable way. And if you practice it properly, you'll be having a lot of fun along the way. Yeah, I think sustainable is a key word there.

Um, in that the project has to be able to run it at a sustainable pace because some projects can last years, um, not all of them, but some can. So for the team to be energized, it needs to be sustainable at a pace that they can manage. Let's right. Yeah. There's going to be periods of intensity in there as well, but we need to be able to see this through for the long haul too.

Thanks so much for listening to the Amazing Apps podcast. You can join the show's mailing list at https://AmazingApps.Show. You'll get a personalized welcome video from yours truly, and a notification when there's a new episode available. 

There are also shortcuts so you can follow the show on all major podcast players and you can follow Amazing Apps Show on Twitter, LinkedIn, YouTube, Instagram, and Facebook.

You can send me a message or a voicemail if you'd like your question answered on a future episode and even support the show through BuyMeACoffee or by buying an Amazing Apps t-shirt.

 Visit https://Amazing.Apps.Show. 

Thanks again for listening. I really appreciate you. Until next time, take care and keep sprinting!