Scrum 353

Alright guys, here we have the Scrum 3, 5, 3. This is the three roles and five ceremonies and three artifacts that exist within Scrum. You can learn more about these items@scrumguides.org so let's go ahead and jump in. The first of three roles we have is the product owner role. The product owner is one of the team members that is responsible for the product backlog and maintaining all of the work that we might do in priority order. They are the voice of the customer. They manage stakeholder expectations and really own all things related to the product that the Scrum teams are working on. The next role is the Scrum Master. The Scrum Master is a team member who is responsible for facilitating all of the Scrum events. They are the team level Agile coach. They're really a servant leader for the team that is an expert in all things scrum. They also shield the team from distractions so the team can get to their committed work. And finally, the third role in the team we have is called developers. Now just to be clear, this doesn't mean that everybody is a software developer. We use the term developer to be inclusive of all of the roles needed to build and release, potentially release the thing of value that the teams are working on. So it could be business analysts and testers and software developers and release management, change management, all of those roles on the team. We call those just developers. Okay, so let's talk about the five ceremonies or events sometimes called on teams. The first one is the Sprint. The Sprint itself is nothing more than a time box and that is typically 10 days, two weeks, they can be shorter, maybe one week, a little bit longer, maybe three weeks. Wouldn't want to be much more than four weeks because it's just too big of a time box to have smaller batches of work for fast feedback. Sprints start one right after the other. There's no break in between them or anything like that. Their lengths don't change. We don't sort of shorten them when we have a holiday or lengthen them when we didn't finish our work. The time box stays the same. Our next ceremony is called Sprint Planning. Sprint Planning occurs at the start of the Sprint. It's where the teams get together and decide on and commit to the work they're going to complete during the sprint. During the 10 day sprint, the product owner presents the work that that person would like to see done. The team members ask questions, they estimate the work and then they commit to the sprint goal for that particular sprint. Our next ceremony is called the Daily standup, as the name might imply, should occur daily. Teams meet regularly daily for the team to know if the team's going to meet the team's commitments. It's not a sort of status updatey type meeting. It's just for team members to know if they're going to make that commitment that they made at Sprint Planning. It's a daily standup. Our next event or ceremony is called the Sprint Retrospective. It occurs at the end of the Sprint and it's at this event that the team members reflect on how they did. They look for ways to improve the Sprint retro is a very transparent moment for teams. It's a critical event for relentless improvement. Teams actually will commit to improvement stories for the next Sprint and they'll go back into the backlog to be prioritized to work on for relentless improvement. The Sprint review event is where the teams look at what they delivered. They demo their software or valuable solution that they've delivered and get feedback from stakeholders and learn and improve as they review what they did in the in the current Sprint. Our first artifact we have is the product backlog. Now, the product backlog is nothing more than a list of all the things we might do for the product. It's in priority order, but it's not a commitment. We haven't committed to doing that we might do it. And the ideas at the top of the backlog have a lot more clarity than the ideas sort of at the lower parts of the backlog or lower priority. The product owner owns the backlog. It's their responsibility to keep it in priority order to refine the backlog and make sure it's got good clarity on the pieces of work that's in the backlog as the teams have questions for it. The product backlog commitment then becomes the product goal. The idea that we have a goal for the product and what it might look like as we're building and pulling work from the product backlog. Our next artifact is called the Sprint backlog, similar to the product backlog, but this actually does represent commitment. So key difference here to keep in mind. Product backlog volatile changing, not committed Sprint backlog well, the Sprint backlog is committed. It's committed by the teams at the Sprint back planning session. It is in priority order, but the teams agree to work on that and we agree to not change the Sprint backlog within the Sprint. It represents our commitment. It also has a committed Sprint goal. So we know what's the goal or goals for our Sprint. It's the Sprint backlog and then we have the product increment as our one of our artifacts. The increment is this idea of the thing of value that we're delivering. It's not a sort of document or anything like that potentially working software that could be shipped and could be made available to users. It's called an increment. It's an increment of work, that thing of value that should the customer want, we could release it. And so there's your overview of the Scrum three five three.