In this video, we will continue with the overview of scrum, and discuss roles and events. We will start by discussing scrum roles. A scrum team is made up of three roles: product owner, scrum master, and development team. The scrum team is made up of cross-functional team members allowing it to complete stories within the team. It is flexible and adaptable with members willing to help out where needed and continuously learning new things. It is self-organizing. The team is responsible for deciding how to organize and do it's work. Stakeholders are not members of the scrum team, but are interested in the success of the project. There are internal stakeholders such as company managers, executives or other scrum teams that rely on the work of the scrum team. There are also stakeholders that are external to the organization such as customers, partners, and investors. The product owner is the member of the scrum team who is responsible for communicating the product vision. The stakeholders and the scrum team need to have an understanding of the product vision in order to work effectively. The product owner is also responsible for maximizing the value of each increment. Each feature that the development team works on should be of high value. The product owner is responsible for the product backlog. Others may help with the product backlog, but the product owner is responsible for it. Stakeholders primarily interact with the product owner. The product owner represents the stakeholders when they are not part of the discussion such as during scrum team meetings. The product owner is accountable to the stakeholders for the success of the project. The scrum master is the member of the scrum team who is primarily responsible for promoting and supporting scrum, for scrum team members as well as stakeholders. It is up to the scrum master to ensure that everyone understands how and why things are done a certain way. The scrum master is also responsible for the day-to-day effectiveness of the scrum team. This includes ensuring that the team is reaching it's goals and continuously improving. The scrum master is responsible for protecting the focus of the team. This may mean helping to remove bottlenecks or ensuring that those outside are interacting with the team in helpful ways. In general, scrum masters do what they need to do to allow team members to focus on their work. The scrum master is also responsible for increasing the transparency of the project. There should be no surprises about the current status of the project. The scrum master's tasks vary by project and from day-to-day. Typical tasks include coaching the scrum team and stakeholders on scrum and agile, helping to remove blocking issues, facilitating scrum events, configuring scrum artifacts, and monitoring sprint progress. This distinction of the product owner and scrum master roles should now be pretty clear. The product owner is responsible for the value of the product. The scrum master is primarily responsible for the effectiveness of the team. You can think of this both as a divide and conquer approach because the work of the roles is so different. Also, as a checks and balances approach because combining the roles could put too much weight on one of the responsibilities. The separate roles lead to greater team success and sustainability. The development team is a cross-functional, adaptive team that does the work of the project. Responsibilities of the development team include: estimating issues- this is usually done using story points, but other estimation methods can be used; deciding on how much work can be done in the sprint- only the development team can decide how much work to take out. It is assumed that the development team is in the best position to forecast how much work the issues take. Deciding how to organize to do the work of the team- this is because the team is an empowered, self-organizing team; creating the increment of each sprint; and finally, the development team are the only members allowed to modify the sprint backlog during the sprint. This is sometimes necessary as the team learns and adjusts as it is building. The Scrum Guide recommends having from three to nine members of the development team. Fewer than three members decreases the productivity and quality created by a cross-functional group of people working together. More than nine members tends to increase the amount of coordination required. Jeff Bezos at Amazon refers to two pizza teams, meaning two pizzas should be able to feed the entire team. To scale scrum to more than nine people, it is usually better to create multiple teams. Next, we will discuss scrum events. A sprint contains four types of events. You may also hear events referred to as ceremonies or simply meetings. The events are the sprint planning meeting, the daily standups, the sprint review, and the sprint retrospective. Scrum events occur at regular intervals and minimize the need for other meetings. These events are designed to maximize the opportunities for feedback, and continuous learning, and are a key part of achieving agility. In between these meetings is where the work of the issues of the sprint is completed. We will discuss each of these meetings separately. All of the scrum meetings have some common characteristics. The meetings have a fixed maximum time limit and no minimum time limit. Meetings can never go over their allotted time, but they can be ended early if the purpose of the meeting is achieved. The meetings are primarily to plan, inspect, and adapt. In agile projects, the planning is distributed throughout the project rather than the mostly upfront planning of waterfall projects. These meetings are an important part of that distributed planning. The meetings are used to inspect the project and adapt with the team is doing based on that inspection. This is a key part of increasing transparency and continuous improvement. The meetings are primarily about the team collaborating, not about updating status. The work is visualized, so you don't need a meeting to see the status. It is the responsibility of every team member to ensure that meetings have value and to help modify them to increase their value if necessary. If the discussion moves in a direction that becomes a value to only a portion of the participants, it should be moved to a later time outside of the meeting. The sprint planning meeting is held at the start of a sprint. The entire scrum team attends the meeting. The duration of the meeting is typically four hours for a two week sprint. If your sprints are four weeks long, you can expect this meeting to be twice as long. The purpose of the meeting is to plan the work of the sprint. The output of the meeting is an agreed upon sprint goal and a sprint backlog. Before the meeting, the product owner usually has a proposed sprint goal and a minimum set of issues that accomplish the goal. These preliminary items often come from the product backlog that has been updated during the previous sprints, sprint review, and sprint retrospective meetings. We will discuss these meetings a bit later. During the meeting, the team usually discusses the sprint goal, modifies the sprint backlog, places story point estimates on issues, and adds details to the issues to better describe the specific work to be done. The development team is responsible for estimating the story points for the work and deciding on how much work can be done during the sprint. They need to do enough planning to have an accurate forecast for the amount of work that they will agree to. The development team also creates subtasks for the first few days of the sprint. The subtasks are often a day or less of work. This is an example of an empowered team rather than a command and control based team. The purpose of the meeting has been met when there is an agreed upon sprint goal and sprint backlog. The sprint backlog contains the issues that the development team has agreed to complete during the sprint, as well as a plan for completing that work. The daily standup meeting is also called the daily scrum. It is a planning meeting that occurs everyday and the participants usually stand as a reminder that it's a short meeting. The meeting usually takes place in the same location at the same time everyday. The development team are the primary attendees for the daily standup. Others may attend the meetings, but are usually asked to listen only. The meeting usually last 15 minutes or less. The purpose of the meeting is to inspect recent progress toward the sprint goal, plan the day's work, and identify any impediments to the team. The team usually makes plans to resolve the impediments, but the discussion often moves to after the meeting. The output of the meeting is the plan for the day. It's important that the daily standup is a collaborative meeting and not simply a status update. The team collaborates to make the best decisions for the day given the latest information. They usually decide on who will work on specific issues, to plan slightly changes after every daily standup. This is continuous improvement. The link at the bottom is a link from the atlassian team playbook on standups. You can find more information there. The sprint review meeting occurs near the end of the sprint. It is an informal meeting that includes the scrum team and interested stakeholders. It is typically a two hour meeting for two week sprints. The purpose of the meeting is to inspect the increment that was just created in the sprint and to collaboratively update the product backlog. This is a meeting with a lot of feedback on the project and includes a brainstorming session to help decide what to do next. The output of the meeting is a first-pass at the next sprint's backlog. By the time the sprint planning meeting happens for the following sprint, the team already has a good idea of what they will be working on. The sprint retrospective is the last event of the sprint. The scrum team attends the retrospective. The meeting typically takes 90 minutes for a two week sprint. The purpose of the meeting is for the team to inspect itself including it's processes, tools, and team interaction. The retrospective is a positive meeting containing constructive feedback. Everyone should always remember that they are part of a team. The scrum master usually helps make sure that this is a positive meeting. The team usually discusses what they should keep doing, what they should stop doing, and what they should start doing. The meeting is about continuously improving the team. The output of the meeting is to add one or more improvement related issues to the next sprint's backlog. It's important that the team spent some of it's time on these issues, rather than exclusively building the product. The link at the bottom is from the atlassian team playbook on retrospectives. You can find more information there. Here's a summary of the four meetings related to a sprint. It's important to always make sure that the meetings have high value and the team should focus on continuously improving their meetings. Notice that the next sprint goal and sprint backlog start to form in the sprint review. The retrospective usually adds one or more issues. This forms the starting sprint backlog for the sprint planning meeting. Here is a review of what we've discussed in this video. Scrum roles include the product owner, scrum master, development team members, and stakeholders. Scrum meetings include the sprint planning meeting, daily standups, the sprint review, and the sprint retrospective. Now, it's time to work on some of the topics discussed in this video and in the previous video. Separate hands on instructions are provided.
