Please finish the assignment by answering the questions about Kanban.
Microsoft PowerPoint - Week9Agile_Scrum_Kanban AGILE: SCRUM AND KANBAN Week 9Nareg Tovmassian Part IV Sprinting Sprint Planning Sprint Execution Kanban Kanban Case Study Week 9 Sprint Planning Scrum activities and artifacts - Framework Sprint Planning: AN OVERVIEW Product backlogs typically contain much more work than can be completed in a single sprint. So each sprint begins with sprint planning. Sprint planning is a recurring, just-in-time activity that occurs at the beginning of each sprint, when the entire Scrum team gathers to agree on a sprint goal and to select a subset of product backlog items it can commit to accomplish during the sprint. PARTICIPANTS IN SPRINT PLANNING Scrummaster can challenge the teams commitment to make sure it is appropriate and realistic, they cannot decide what commitment to make. Product Owner shares Sprint Goals, prioritized PBI, answers questions. Development team determines what they can work on. The full Scrum team collaborates during sprint planning - the development team, the product owner, and the ScrumMaster. INPUTS TO SPRINT PLANNING Sprint planning relies on a set of inputs that guide the development team in determining what value it can realistically deliver during the sprint. These sprint planning inputs are as follows: Product Backlog. The highest priority PBIs should already be groomed, which typically means the PBIs have acceptance criteria, and have been sized appropriately, estimated, and prioritized. Team Velocity. The team's historical velocity is one predictive indicator of how much work is practical for the team to complete in a single sprint. Constraints. The team should have identified any business or technical constraints that could materially affect what the teams can deliver. Team Capabilities. The team should know which team members are available (and availability) for this particular sprint, along with skills each team member has. Initial Sprint Goal. The product owner should have identified the business objective they ideally would like to see accomplished during the sprint. OUTPUTS OF SPRINT PLANNING At the end of sprint planning, the development team communicates its commitment through the two sprint planning outputs: a finalized sprint goal and a sprint backlog. SPRINT PLANNING PROCESS 1. Divided into the what and the how. First the team determines its capacity to complete work and forecasts the PBIs the product owner has requested that it believes it can deliver by the end of the sprint. 2. In part 2, the team acquires confidence in its ability to complete the items it forecasted in part 1 by creating a plan. 3. The team then compares the estimate of task hours against its capacity, in terms of hours, to see if its initial commitment was realistic. 4. When the team's forecast is comfortably within its capacity range and restraints, it finalizes its commitment and sprint planning is over. Two-Part Sprint Planning SPRINT PLANNING PROCESS 1. Using this approach, the development teams begins by determining its capacity to deliver work. 2. Based on available capacity, the sprint goal may need to be refined. 3. Next, the team selects the highest priority requested product backlog item and acquires confidence that the selected item will reasonably fit within the sprint, given other items already included in the team's evolving commitment. 4. This cycle is then repeated in priority order until the team is out of capacity to do any more work. At that point, the team finalizes its commitment and sprint planning is over. One-Part Sprint Planning Sprint planning process- Determine Team Capacity A team's capacity is the estimated total number of hours the team will have available to work on product backlog items during the sprint, minus other regular sprint activities, non-sprint commitments, and planned time off. The capacity should take into account individual team member skills as well, especially highly specialized skills that might have very limited availability during a sprint. Capacity can be measured in story points or in effort hours. Velocity can use long term average velocity or previous Sprints velocity. Sprint planning process- Selecting backlog item Default - select items from top of PBI Select PBIs that align with Sprint Goals Don’t select what you can't finish (WIP and technical debt principles reduce waste) Sprint planning process- Acquire Confidence One way a team can acquire confidence in its ability to deliver a set of product backlog items during the sprint is to use historical velocity to see if the commitment is realistic. A sprint backlog that exceeds a team's historical velocity average should be a red flag. Better to break down product backlog items down into the tasks that are required to complete. (see fig-next slide) These tasks can then be estimated and subtracted from the team's capacity, if the capacity has been expressed in effort hours. Use JIT along with team input! Sprint planning process- Acquire Confidence Sprint planning process- Refine the Sprint Goal & Finalize the Commitment The sprint goal summarizes the business purpose and value of the sprint. The product owner comes to sprint planning with an initial sprint goal, but the sprint goal would be refined over the course of sprint planning to match the reality of what can be delivered during the sprint. At the completion of sprint planning, the development team finalizes its commitment to the business value it will deliver by the end of the sprint. This commitment is expressed in a refined sprint goal and sprint backlog. Refine the Sprint Goal Finalize the Commitment Sprint Execution Sprint Execution: AN OVERVIEW Every sprint, the team executes a mini-project unto itself—it performs all of the work necessary to deliver a potentially shippable product implement. The team's work is guided by the sprint goal and sprint backlog. Sprint Execution Timing & Participants The majority of the team's time each sprint should be spent in sprint execution. It begins after sprint planning and continues until the sprint review begins. For a two-week sprint, sprint execution would likely count for 8 of the 10 days. Timing Participants During sprint execution, the development team members self-organize to determine the best way possible to meet the sprint goal. The ScrumMaster coaches, facilities, and removes any impediments that block or slow the team's progress. The product owner is available to answer questions, review intermediate work, and provide feedback to the team. The product owner might also be called upon to discuss adjustments to the sprint goal or to verify acceptance criteria. Sprint Execution Process Outputs from Sprint Planning Sprint Execution Process – Flow Management Parallel Work and Swarming During sprint planning the team produces a high-level plan for how to achieve the sprint goal, usually in the form of a sprint backlog. Team members perform just-in-time task-level planning as needed, as opposed to trying to formulate a detailed plan. 1. Sprint execution/Task Planning 2. Flow Management It is the team's responsibility to manage the flow of work throughout the sprint to meet the sprint goal. This includes making decisions about how much work the team should do in parallel, which work to start, how to organize the task-level work, which work to do, and who should do the work. Sprint Execution Process – Flow Management Parallel Work and Swarming The team must determine how many product items to work on in parallel. Working on too many items at once slows the team down. But working on too few items at once is equally wasteful. The teams should work on the number of items that leverages but does not overburden the T-shaped skills and available capacity of the team members. The goal is to reduce the time required to complete individual items while maximizing the total value delivered during the sprint – called Swarming. Swarming is when team members with available capacity work together to complete one unfinished item rather than moving ahead to work on new items. Teams will have to experiment to find the balance that maximizes the value they deliver each sprint. 2. Flow Management - Parallel Work and Swarming Teams need to stay away from multitasking or Waterfall approaches! Sprint Execution Process – Flow Management Continued The simplest way to choose the product item to work on next is to select the highest-priority item as specified by the product owner. In reality, dependencies or skills capacity constraints might dictate a different order. The development team should be enabled to opportunistically select work as appropriate. 2. Flow Management Which Items to Start How to Organize Task Work What Tasks Needs to Be Done? Who Does the Work? It's best to approach the work from a value and delivery-focused mindset. This means minimizing the amount of time work sits idle and reducing the size of handoffs Approaches like XP keeps work flowing, supports very fast feedback, and enables team members with T-shaped skills to swarm on an item to get it done. The team should decide which task-level work it needs to perform to complete a product backlog item. POs and stakeholders influence these choices by defining the scope of a feature and creating acceptance criteria. Overall, the team and the product owner must work together decisions are made in an economically sensible way. The person best able to quickly and correctly get it done! If that person is unavailable, the team should decide on the next best person. Use T-Shape skills and swarming. Sprint Execution Process – Daily Scrum & Task Performance The daily scrum is a critical is a 15-minute, timeboxed daily inspect-and-adapt activity to help the team achieve a faster, more flexible flow toward the solution. The purpose of the daily scrum is to get the people who are focused on meeting the sprint goal together to share the big picture of what is happening so that they can understand how much to work on which items to start working on 3. Daily Scrum 4. Task Performance—Technical Practices Development team members are expected