Project Scenario 4 Sprint Release Management

Story ID
Name
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Mobile Device Implementation
Intranet/Internet Network Hardware (HW)
Install and configure network software (SW), etc.
Communication infrastructue QA and testing
Install/configure Server O/S (Windows Server)
Install/configure SharePoint
Install/configure CIA Package XYZ-231
Install/configure SQL Server
Install/configure connectivity SW & do QA
Install/configure security SW/HW & do QA
Install/configure developer HW/SW stations & access
Install XYZ Corporation Biohazard Portal (Build 21Q)
Field Bio-hazard Team Workpackage Interface
Central Dispatcher/Observer Interface
XYZ C Mobile Case Management System (Build 11C)
Custom Lab Application Data Input Interface
Custom Lab Application Data Results Access Interface
Custom Emergency Communications Interface
Custom CIA/NSC Bio-hazard Interface & Data Access
Custom Public Health Information Interface
Custom Biohazard Mobile Field Log
Custom Field Bio-hazard Team Interaction Application
Custom Utility Package
QA for Fully Functional Portal per Specs
BITCS – Biohazard Incident Tracking & Coordination System
N/A = Not applicable (completed)
Description
Product Owner Order Preference #
Mobile device HW & SW installation/configuration
Network infrastructure HW, cabling, wireless, etc.
Network software for included hardware (routers, etc.)
Communication infrastructue QA and testing
Install/configure Server O/S (Windows Server)
Install/configure SharePoint, etc.
Install/configure CIA Package XYZ-231 (Top Secret)
Install/configure SQL Server
Install/configure connectivity SW & do QA
Install/configure security SW/HW & do QA
Install/configure developer HW/SW stations & access
Install XYZ Corporation Biohazard Portal (Build 21Q)
Field Bio-hazard Team Workpackage Interface
Central Dispatcher/Observer Interface – Control
XYZ C Mobile Case Management System (Build 11C)
Custom Lab Application Data Input Interface
Custom Lab Application Data Results Access Interface
Custom Emergency Communications Interface
Custom CIA/NSC Bio-hazard Interface & Data Access
Custom Public Health Information Interface
Custom Biohazard Mobile Field Log
Custom Field Bio-hazard Team Interaction Application
Custom Utility Package
QA for Fully Functional Portal per Specs
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
1
2
3
4
5
6
7
8
9
10
11
12
Estimated Work Hours
Status
200 hours
200 hours
100 hours
100 hours
100 hours
100 hours
50 hours
100 hours
100 hours
200 hours
100 hours
100 hours
150 hours
100 hours
300 hours
100 hours
100 hours
150 hours
200 hours
50 hours
125 hours
250 hours
50 hours
100 hours
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
Completed
To be completed
To be completed
To be completed
To be completed
To be completed
To be completed
To be completed
To be completed
To be completed
To be completed
To be completed
To be completed
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 the roles of your IFSM 441 team
members. Aside from your assigned role, you should self-organize and share responsibilities to
help your team meet its assignment requirements, sharing the workload as equally as is feasible.
Overview of Scenario #4 Task Assignment
At this juncture, back in Scenario #3, your team has submitted the project’s high-level release
plan and associated details. It’s time to focus on the sprint level, where in Scenario 4 work tasks
are estimated by hours (not function points or story points)and assigned to one or more sprints.
Each sprint is carried out by the development team, and performance is managed and assessed.
Your task assignment is to develop a High-Level Report in the form of a consolidated
Executive Summary, for Scenario #4, with the following 5 deliverables integrated into the
report:
1. Estimation Exercise – The gist of this exercise is to fit the appropriate number of stories
into one or more sprints based on estimated hours. See background information in
Lecture Notes, assigned readings, and your own web searches.
2. Sprint Backlog Exercise – The gist of this exercise is to survey and define the sprint
backlog. See background information in Lecture Notes, assigned readings, and your own
web searches.
3. Daily Scrum Meeting Exercise – The gist of this exercise is in a one-half page narrative
to describe a “fantasy” description of a Daily Scrum Meeting for your team, based on
your readings on daily Scrum meetings. The meeting should focus on the interactions
between the ScrumMaster and Delivery Team. See background information in Lecture
Notes, assigned readings, and your own web searches.
4. Sprint Burndown Chart Exercise – The gist of this exercise is to develop a chart graphic
of your sprint burndown.See background information in Lecture Notes, assigned
readings, and your own web searches.
5. Release Burndown Chart Exercise – The gist of this exercise is to develop a chart graphic
of your release burndown. See background information in Lecture Notes, assigned
readings, and your own web searches.Task Requirements
6. Team scoring table: Reuse the scoring table your team developed in Scenario #3 and
reassess the team. Only the scoring table is required and not the team building
narratives.There are no additional instructions contained in the “Scenario 4 Exercise
Sheet.docx” document; however, this is a required deliverable for Scenario #4.
Other Guidance
1. Follow the approaches, methodologies, conventions, and formats presented in the Lecture
Notes, assigned readings, and as you take note of in helpful web searches unless
otherwise directed by the instructor;
2. Follow all guidelines in the provided assignment rubric to maximize your grade; and See
the Course Syllabus, related Course Content area files, and LEO Classroom News as
needed for supporting information.
Scenario #4 Grading Rubric
Attribute
Full Points
Partial Points
No points
Estimation
Exercise
The response is
The response is No minimally
per Agile
not sufficiently acceptable
principles and
per Agile
presentation of
values,
principles/values, value.
appropriate, well appropriate, or
developed, and
well developed
well presented
and presented.
with no errors in
content or English
usage.
Possible
Points
20
Sprint Backlog The response is
The response is No minimally
Exercise
per Agile
not sufficiently acceptable
principles and
per Agile
presentation of
values,
principles/values, value.
appropriate, well appropriate, or
developed, and
well developed
well presented
and presented.
with no errors in
content or English
usage.
20
Daily Scrum
Meeting
Exercise
The response is
The response is No minimally
per Agile
not sufficiently acceptable
principles and
per Agile
presentation of
values,
principles/values, value.
appropriate, well appropriate, or
developed, and
well developed
well presented
and presented.
with no errors in
content or English
usage.
20
Sprint
Burndown
Exercise
The response is
per Agile
principles and
values,
appropriate, well
developed, and
20
The response is No minimally
not sufficiently acceptable
per Agile
presentation of
principles/values, value.
appropriate, or
well developed
Points
Earned
well presented
and presented.
with no errors in
content or English
usage.
Release
Burndown
Exercise
The response is
The response is No minimally
per Agile
not sufficiently acceptable
principles and
per Agile
presentation of
values,
principles/values, value.
appropriate, well appropriate, or
developed, and
well developed
well presented
and presented.
with no errors in
content or English
usage.
20