IFSM 441 SCENARIO 4

Scenario 4 – Sprint/Release Management Practices

IFSM 441 – Agile Project Management

October 6, 2019

Team Members

Robert Barkley Craig Carmichael-Spier

Joshua Horning Ashley Mate Scott Phillips

Maureen Sullivan

2

Table of Contents

EXECUTIVE SUMMARY................................................................................................3

SCENARIO 4 – EXERCISE 1 (ESTIMATION EXERCISE).....................................................4

Analysis and Rational For Stories in Sprint................................................................................4

SCENARIO 4 – EXERCISE 2 (SPRINT BACKLOG EXERCISE).............................................6

SCENARIO 4 – EXERCISE 3 (DAILY SCRUM MEETING EXERCISE)....................................8

SCENARIO 4 – EXERCISE 4 (SPRINT BURNDOWN CHART EXERCISE)...............................9

SCENARIO 4 – EXERCISE 5 (RELEASE BURNDOWN CHART EXERCISE)..........................10

SCENARIO 4 – EXERCISE 6 (TEAM SCORING TABLE)....................................................11

REFERENCES............................................................................................................12

3

Executive Summary

XYZ Corporation has been tasked to use agile project management methodologies to

design and build the Biohazard Incident Tracking and Coordination System (BITCS) for the U.S.

Homeland Security Agency. Group 3 of XYZ Corporation has been assigned to this project.

Fortunately, the Product Owner has supplied Group 3 with a backlog list of stories that must be

accomplished. The list is ordered by priority and lists the predecessors for the various story

components. Group 3 consists of a Product Owner Coordinator, a Scrum Master, a Team

Coordinator, and eleven developers. This assignment has been divided into five exercises: 1)

Estimation Context; 2) Sprint Backlog Context; 3) Daily Scrum Meeting Context; 4) Sprint

Burndown Chart Context; and 5) Release Burndown Chart Context.

4

Scenario 4 – Exercise 1 (Estimation Exercise)

Estimation Hours Exercise for BITCS Product Backlog (Remaining To-Do Backlog)

The table below shows the set (list) of stories that will be included in the month-long sprint

under planning by Group 3, the Product Owner, the Scrum Master, and the Scrum Team.

Description (Stories) Product Owner Order

Preference #

Hours Estimated Work Hours

Status

Field Bio-hazard Team Workpackage Interface

1 150 150 hours

To be completed

Central Dispatcher/Observer Interface – Control

2 100 100 hours

To be completed

XYZ C Mobile Case Management System (Build 11C)

3 300 300 hours

To be completed

Custom Lab Application Data Input Interface

4 100 100 hours

To be completed

Custom Lab Application Data Results Access Interface

5 100 100 hours

To be completed

Custom Public Health Information Interface

8 50 50 hours

To be completed

800

Analysis and Rational For Stories in Sprint

After reviewing the remaining to-do backlog set (list) of stories, Group 3 Scrum Team

and Scrum Master held a Sprint Planning meeting to determine which stories could be

accomplished in a one month (4 weeks) sprint. The Product Owner has listed the priority of each

story and outlined these stories in the table above. Based on the team’s one-month sprint capacity

(approximately 800 hours) and the priority of stories to execute, Group 3 decided to include the

stories listed in the table above in the one month sprint. Essentially, the stories chosen will allow

the team to successfully accomplish the tasks in the listed stories within the time manageable in a

5

one month sprint. In summary, the results of the Sprint Planning allowed all team members

(Product Owner, Scrum Master, Scrum Team) to develop a plan to accomplish half of the

remaining project tasks within a one-month sprint (approximately 800 hours).

6

Scenario 4 – Exercise 2 (Sprint Backlog Exercise)

STORY ID: 21 Custom Biohazard Mobile Field Log (125 Hours)

USER STORY TASKS Day 1 Day 2 Day 3 Day 4 Day 5 Week Totals

As a team member, I can record the key data on potential biohazards identified during field incident deployment

Decide items to be present within log

4 0 0 0 0 4

Document Requirement s for design

2 0 0 0 0 2

Develop Wireframing for app design

8 0 0 0 0 8

User Interface design

8 0 0 0 0 8

Determine Technology Stack for mobile application

2 0 0 0 0 2

Develop field log application back-end

8 8 8 4 4 32

Develop Application Programming Interface

0 0 8 8 6 22

Develop Front-End of application

0 0 8 4 2 14

Function Test 0 0 2 4 4 10

Usability Test 0 0 2 4 4 10

Performance Testing

0 0 2 4 4 10

Regression Testing

0 0 0 0 3 3

TOTALS 32 8 30 28 27 125

7

In developing the Sprint backlog for Story ID 21, Group 3 focused on the application

development for the Biohazard Mobile Field Log. The “process (for application development)

requires proper planning, research, skills, and above all, a clear focus” (IntellectSoft, 2019, para.

4). The first four tasks are designing the application on paper before any code is developed. The

last four tasks include testing the application before delivery to the customer known as regression

testing where “teams will have a list of tests to perform at the end of each sprint, which will

include tests from previous sprints” (Francis, 2015, para. 39). The Custom Biohazard Mobile

Field Log (above) is an estimation of work for Story ID 21, and the tasks needed to complete it.

Notably, it lists more than the three-to-six task range due to complexities of application

development and how each task would be broken out.

8

Scenario 4 – Exercise 3 (Daily Scrum Meeting Exercise)

The purpose of daily SCRUM meetings is used to get all teammates together to review

how the tasks are shaping up so plans can be adjusted as needed for the next iteration/sprint of

the project in the business week (Rouse, n.d.). The daily SCRUM meeting is set for Wednesday,

halfway through the five-day sprint for Story ID 21. The goal of the story is for Group 3 to create

a field log that will be implemented to collect data on biohazards in the field for research. The

duration of this daily meeting is fifteen minutes, and it is held at the close of every meeting at the

same time each day, it is meant as a collaboration of the team to discuss the status of the project.

Essentially, the Scrum Master will ensure that the team members from the development team

will be present to discuss the needs of the project and that each team member stands to eliminate

the need for running over the allotted time for the meeting duration (SCRUMstudy, 2013). The

Scrum Master is also responsible for ensuring that all roadblocks faced by the development team

are quickly addressed and that the team meeting stays within the fifteen minutes timeframe as

well. The Group 3 Team Coordinator will be in charge of requesting input for the sprint backlog

from each of the team members, asking succinct and brief feedback for any roadblocks that may

hinder the progress. Additionally, this input will assist the team with facilitating solutions that

will allow the work to continue (SCRUMstudy, 2013). The Wednesday meeting is to ensure that

the Group 3 development team is in agreement for the next day of the sprint, and as such, the

remaining members of the team will be placed to listen and offer input as needed.

9

Scenario 4 – Exercise 4 (Sprint Burndown Chart Exercise)

During the daily scrum meeting, the scrum team updates the spring backlog (Mountain

Goat Software, 2019). In fact, “Once each day, the estimated work remaining in the sprint is

calculated and graphed by the Scrum Master, resulting in a sprint burndown chart” (Mountain

Goat Software, 2019, para. 4) like chart listed below. This chart is based on a one-month sprint

(800 hours/20 days) produced by the Scrum Master in February 2013.

10

Scenario 4 – Exercise 5 (Release Burndown Chart Exercise)

The Release Burndown Chart shown below illustrates how the required hours to complete

BITCS Backlog List of Stories will be decremented over time until the number of hours is zero.

11

Scenario 4 – Exercise 6 (Team Scoring Table)

Please provide an overall score (rating) for your fellow group team members by checking one box beside each member’s name.

TEAM MEMBER NAME (5) =Extremely Helpful

(4) = Very Helpful (3) = Somewhat Helpful

(2) = Not So Helpful

(1) = Not at all Helpful

Robert Barkley

Craig Carmichael-Spier

Joshua Horning

Ashley Mate

Scott Phillips

Maureen Sullivan

12

References

Francis, P. (2017, June 5). Mobile app development process: An in-depth overview. Retrieved

from https://thebhwgroup.com/blog/mobile-app-development-process

IntellectSoft. (2019, September 2). iOS app development process entry-level guide. Retrieved

from https://www.intellectsoft.net/blog/ios-app-development-process

Mountain Goat Software. (2019). Sprint backlog. Retrieved from

https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/sprint-backlog

Rouse, M. (n.d.). What is agile retrospective? - Definition from WhatIs.com. Retrieved

from https://searchsoftwarequality.techtarget.com/definition/Agile-retrospective

SCRUMstudy. (2013, December 10). Colocated team vs. distributed team in scrum. Retrieved

from http://blog.scrumstudy.com/colocated-team-vs-distributed-team-in-scrum/