Scenario 4: Estimation, Sprint Backlog, Daily Scrum Meeting,
evfliyseozona
Scenario4ExerciseSheetV3.docxScenario 4 Exercise Descriptions and Requirements
Exercise Descriptions and Requirements Overview
These five exercises that follow are to be submitted in your Assignments Folder in one file, or as few files as is practically feasible, according to each student’s preferences. 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 posted in Conference 6. 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 posted in Conference 6 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 on PP. 12-13 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 posted in Conference 6 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 P. 10 in 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 P. 13 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 posted in Conference 6 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 on P. 14 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 same data set posted in the Scenario 3 BITCS Product Backlog file, posted in Conference 5. 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
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. Remember, per this specification, you are to use the Scenario 3 BITCS Product Backlog file as posted in Conference 5, and to assume that the hours/story points are in sync with the story data listed in the referred to spreadsheet (without any labor constraints, etc.). Feel free to vary the graphical representation according to your tool capabilities and your preferences.
