complete scenario 4
Scenario 4 Exercise Descriptions and Requirements Exercise Descriptions and Requirements Overview This document describes the five required exercises that collectively makeup Scenario 4, along with instructions and tips for going about completing the exercises. First, let’s set the project context. This Scenario 4 uses a similar BITCS Product Backlog file as the one used in Scenario 3 but has differences. The stories in the spreadsheet are the same, but the time juncture is different. Unless otherwise instructed (see Exercise 5), use the Scenario 4 BITCS Product Backlog file. Note that stories 1-12 have been completed at this file’s time context. Exercise 1 Exercise 1 (Estimation) Context As noted in the “Estimation Meeting” section of the Webliography document Do Better Scrum, the purpose of the estimation meeting is for the Scrum Team to meet to size backlog work items (stories) for the purpose of estimating how much work (how many work items or stories) can be put in a particular timeboxed sprint. Exercise 1 Overview The sprint’s stories used in this exercise are drawn from the remaining-to-do backlog, based on the data in the Product Backlog file that has been agreed on by the Product Owner, the Scrum Master, and the Scrum Team. While there are many ways to estimate how stories can be “loaded” from the Product Backlog into the Sprint Backlog (such as using story points, value points, and hours estimated), XYZ Corporation follows the sprint hour estimation techniques of Agile luminary Mike Cohn, as summarized in the following posting: http://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning Exercise 1 Background Metrics - Team Makeup/Size: No need to consider for the purposes of this exercise - Team Capacity (Historical Average of Estimated Hours Team Can Execute in Month-long Sprint): 800 - Sprint Length: 1 month (4 work weeks) Exercise 1 Requirements Analyze the Scenario 4 BITCS Product Backlog file and determine the set (list) of stories that should be included in the month-long sprint under planning at this juncture, and then state the results of your analysis and your rationales in one well-written paragraph. Exercise 2 Exercise 2 (Sprint Backlog) Context As noted in the “Sprint Backlog” section of the Webliography document Do Better Scrum, the purpose of the sprint backlog is to tell the whole team and anyone else what work they have planned for the sprint and their current status. The time context for this exercise is just before the sprint begins. While this Exercise 2 follows generally in a time context after Exercise 1, the Exercise 1 information is not relevant here for the purposes of Exercise 2. Exercise 2 Overview In this exercise, you will use the data in the Scenario 4 BITCS Product Backlog file to devise a part of a sprint backlog file. In particular, you will build only the part of the sprint backlog that relates to StoryID 21 (Custom Biohazard Mobile Field Log). The purpose of this story is to develop a field log for gathering empirical data on potential biohazards identified in the field. The full story text follows: As a team member, I can record the key data on potential biohazards identified during field incident deployment. See the following link for helpful related details on the contents of sprint backlogs, and, as a tip, note what is contained in these typical entries for a story: http://www.mountaingoatsoftware.com/scrum/sprint-backlog Exercise 2 Background Metrics - Team Makeup/Size: No need to consider for the purposes of this exercise - Number of Total Team Hours to Execute This Story (per the spreadsheet): 125 - Number of Tasks Expected by the Course Instructor: 3-6 - Number of Work Days to Execute This Story: 5 Exercise 2 Requirements Using the sprint backlog at the link above as your guide, develop a similar MS Word table to serve as the sprint backlog excerpt in this exercise. You will need to use your imagination and/or systems analysis expertise to develop the individual tasks relating to this story. The link above will give you some ideas on how the story may be broken into tasks. Likewise, using your imagination and/or systems analysis expertise, you will need to make an estimate of the daily breakdown of hours to get to the total of 125 at the end of the prescribed 5 days allowed for executing this story. I recommend adding a refinement to the link example: totaling your estimated hours for the day and week. Remember, as stated, above, the time context is before the start of the sprint, so this is actually an estimate. Exercise 3 Exercise 3 (Daily Scrum Meeting) Context As noted on the “Daily Scrum Meeting” section of the Webliography document Do Better Scrum, the purpose of the daily Scrum meeting is to meet daily to communicate and synchronize work among team members. The time context for this exercise is the Wednesday (half-way point) in the week of work that is the focus of Exercise 2. Exercise 3 Overview Given the stated context for the Daily Scrum Meeting provided in the first section, you are to consider what an “average” daily Scrum Meeting may look and sound like if you were there. Be sure to consider all the role perspectives in describing how the 15-minute meeting may run. Exercise 3 Background Metrics - Team Makeup/Size: No need to consider for the purposes of this exercise - Length of Scrum Meeting: 15 minutes Exercise 3 Requirements Analyze your outcomes in Exercise 2 and, based on the do’s and don’ts of Daily Scrum Meeting conventions, describe how the Wednesday meeting is likely to run, based on do’s/don’ts, in a one-half page narrative. Be sure to consider all the role perspectives in describing how the 15-minute meeting goes. Exercise 4 Exercise 4 (Sprint Burndown Chart) Context As noted on in the “Sprint Burndown Chart” section of the Webliography document Do Better Scrum and the following link http://www.mountaingoatsoftware.com/scrum/sprint-backlog , the purpose of the sprint burndown chart is to help the team monitor its progress and be an Indicator of whether the team will meet its commitment at the end of the sprint. Exercise 4 Overview In this exercise, you will use the same data set in the Scenario 4 BITCS Product Backlog file that you used for Exercise 1, that is, you are to do a sprint burndown chart for the one-month sprint; however, for the purposes of this burndown chart, you will follow the metrics described in the “Exercise 4 Background Metrics” of this section. Your burndown chart will look similar to the one depicted in the link above, except your burn down chart will accurately reflect the data in the metrics section that follows. Exercise 4 Background Metrics - Team Makeup/Size: No need to consider for the purposes of this exercise - Number of Total Hours Required to Execute This Sprint: 800 or less (same as your Exercise 1) - Number of Weeks in Month: 4 (Month – February 2013) (20 work days) - Velocity of Work Completed: 200 hours of work stories completed per week Exercise 4 Requirements Using MS PowerPoint, MS Word, or MS Visio (or another product if saved to a .jpg or .pdf file and integrated into the master Scenario 4 document or submitted separately), develop a sprint burndown chart graphic that meets the specifications stated. Feel free to vary the graphical representation according to your tool capabilities and your preferences. Exercise 5 Exercise 5 (Release Burndown Chart) Context As noted in the “Sprint Burndown Chart” section of the Webliography document Do Better Scrum, the purpose of the release burndown chart is to measure and illustrate the rate of delivery of a stream of running, tested, features over time. This rate is known as the team’s velocity. For the purposes of this chart, you will use the same scope of analysis used for the release plan you did for Scenario 3 (or the way you are requested to do it here), that is, for a 4-month period and including successful completion of all the stories that your solution deemed as successful (or that you wished you had). Either approach is OK here. Exercise 5 Overview In this exercise, you will use the BITCS Backlog List of Stories for Scenario 4. Your burndown chart will look similar to the one depicted in the Do Better Scrum document, or using a different graphical representation. The main thing is to show how the required hours to complete the stories will be decremented over time until the number of hours is zero. Exercise 5 Background Metrics - Team Makeup/Size: No need to consider for the purposes of this exercise - Number of Total Hours Required to Execute This Release: BITCS Backlog List of Stories for Scenario 4 - Time Length to Complete Release: 4 months - Number of Sprints in 4-month Period: 4 - Average Time Length of Sprint: 1 month Exercise 5 Requirements Using MS PowerPoint, MS Word, or MS Visio (or another product if saved to a .jpg or .pdf file and integrated into the master Scenario 4 document or submitted separately), develop a release burndown chart graphic that meets the specifications stated. Feel free to vary the graphical representation according to your tool capabilities and your preferences. Scenario #4 (Sprint/Release Management Practices- Group Project) UMUC IFSM 441 Scenario 4: Estimation, Sprint Backlog, Daily Scrum Meeting, and Performance Management Due Week 7 Introduction Before you begin this assignment, be sure you have read the “XYZ Corporation Case” and Scenario #3.This is a continuation of Scenario #3. Purpose of the Assignment This assignment gives students the opportunity to apply IFSM 441 course concepts and specifically addresses the following course outcomes: 1. Evaluate the values, principles, strategies and practice of Agile tools in order to mitigate uncertainty and risk with project delivery. 2. Compare Agile versus traditional project methodologies in order to provide thebest fit for the organization. 3. Apply Agile framework to meet the specific operational needs. 4. Evaluate and implement performance measures in order to assess thesuccess of an Agile project. Your Group and Assigned Roles This assignment your Scenario #3 Agile Role rotates to a new role as follows: 1. Scenario #3 Scrum Master to Scenario #4 Product Owner Coordinator 2. Scenario #3 Product Owner Coordinator to Scenario #4 Team Coordinator 3. Scenario #3 Team Coordinator to Scenario #4 Scrum Master You are to divide into teams of 3 persons (or 2 or 4 persons if needed). In a 3-person team, one person will assume each of the following three roles: 1) Scrum Master – focus on process; 2) Product Owner Coordinator – focus on the product (interfacing as needed with the instructor who serves as Product Owner); 3) Team Coordinator – focus on the developer team inputs (you represent the voices of 11 developer team members (including 2 .NET developers, 2 SQL Server developers, 2 SharePoint developers, 2 quality assurance specialists testers, 2 business analysts, and 1 technical writer). Your roles within the team are assigned to you via rotation from Scenario #3, as indicated above. Reference the key roles in Agile/Scrum projects in the Lecture Notes and assigned readings to better understand your assigned role and