Question

Third Avenue Software is a relatively young company that develops mobile applications for phones. The company is still trying to find its corporate identity and permanent footing; it has released several moderately successful products but is still looking for a best-seller. Likewise, the company is still trying to determine which internal systems work best for its employees. Project management is among these systems. The company has used a few agile principles in previous projects with some success; its new project will use agile and Scrum whenever possible.

Many of Third Avenue’s products thus far have been designed to serve niche markets, so the company’s cofounders instructed their marketing staff and programmers to identify markets that have more universal customer appeal. A couple of programmers quickly turned their focus to the field of health care, which affects everyone directly or indirectly. The programmers drafted an idea for an app that could serve as a “one-stop shop” for customers’ health-care information and needs. The app’s name is to be determined, but it will contain the following features and information. Because Third Avenue knows from experience with agile projects that software complexity ratings can be useful for later time and cost estimates, management asked the programmers to include initial complexity estimates for each major feature set. These numbers are shown in parentheses and use a scale of 1 to 8:

• A fitness tracker that allows customers to record and track their blood pressure readings, cholesterol levels, exercise regimen, calorie intake, and other related information (3).
• A medication tracker in which customers can enter their medications and schedules for taking those meds. This “electronic pillbox” will contain a calendar that displays the customer’s medication schedule and an alarm that sounds whenever it’s time to take one of the medications (3).
• A physicians list that is essentially an electronic address book for the customer’s health-care company, doctors, nurses, and physician’s assistants. The list will include controls that allow customers to quickly incorporate existing entries from other contact lists in their phones (2).
• An emergencies list for storing vital phone numbers and addresses. This list will provide quick access to local in-network hospitals, urgent care clinics, and children or friends who can be relied upon to provide transportation in an emergency. As soon as the customer enters and saves an address, an interactive GPS map becomes available in a new window, with voice and text directions (6).
• An emergency information list in which customers store important information about themselves, such as medical conditions (e.g., the customer is diabetic), allergies, adverse reactions to drugs, and other personal information that a physician, nurse, or other concerned party might find useful in an emergency (2).
• A resources feature that lists links to other popular online health sites, such as WebMD. The customer will have the option to add links to the list (1).
• A payment feature that tracks the customer’s medical expenses and allows customers to make medical payments through their phones (4).

The budget for the project is $350,000, and Third Avenue management would like to see a finished application available in four months.

Scrum will be the preferred approach to managing the project’s development because Third Avenue wants a working version of the application quickly but does not yet know the full scope of the project. This working version will be released for review and testing well before the planned official release in four months. Remember that agile projects involve numerous iterations and software versions before the final release. These versions should be responsive to the concerns expressed by all stakeholders.

For example, programmers assigned to the app’s development might be needed to provide support for other company projects, and more functionality might be added to the app after various stakeholders have had an opportunity to evaluate the first working version.

Usability

Usability will be extremely important, as customers will tend to be older than those who download and buy the majority of mobile apps. For example, the app will require a prominent control for increasing the text display size. Such controls are available in a phone’s Settings feature, but many older users tend not to explore such “hidden” settings.

The features mentioned above need to be immediately available and easily accessible when the app is launched.

Another usability issue is crucial: How does the app balance customer privacy against the need to share some of the customer’s information in an emergency? For example, the emergency information list might be of no use in a medical emergency if the customer’s phone access is blocked by a password that only she knows.

Taken as a whole, programmers give usability issues a complexity rating of 4 on a scale of 1 to 8.

Monetizing the App

Another unknown is the question of how to monetize the app most effectively—for example, the app will use ads, but how? Pop-up ads are an annoyance to many people; will they be tolerated by users or will they be immediately rejected? Will the app offer premium services, and if so, what are they? Will a subscription paywall be viable after an initial period of free use?

Project Team

As one of the two senior programmers at Third Avenue, you have been selected to run the project for developing the health-care app. You will be joined by the following colleagues on the project team:

• Eric, a junior programmer who is considered by his peers to be the author of some of the best code at the company. You have also designated Eric to be the project ScrumMaster.
• Lia, another talented young programmer
• Brianna, a marketing representative who has experience in health care from a previous job
• Jack, the regulatory manager at Third Avenue
• Kendra, the Quality Assurance manager

Project Scope

Remember that project scope management is different in agile projects than in traditional project management. For example, participants in agile projects typically spend less time defining scope in early stages of a project. However, Third Avenue has high hopes for the health-care app and wants to make sure that all team members work out some basic, crucial requirements before proceeding. Also, agile projects generally require more iterations of working software than in traditional project management, so management must be willing to trust the process once the basic requirements are in place and understood.

To help develop scope, agile and Scrum approaches employ cards, user stories, and technical stories. User stories are often written on index cards and then arrayed on a wall or table top to help the agile team plan how to implement the ideas into the product. Technical stories are then developed from the user stories. Technical stories can contain one or more technical tasks that developers use to chart progress on a sprint board as work is conducted throughout a sprint. This approach facilitates group discussion, which often leads to a much better set of product specifications than the rather simple ideas expressed on the cards.

One of management’s key goals is to have the team develop ideas for completing a minimum viable product (MVP) as soon as possible. An MVP is a streamlined, stripped-down version of a product that can still be released for real-world use and review. It contains a subset of features that will be included in the final version. An MVP must possess several key properties:

• It has sufficient usable features and value that users will buy it.
• These early users will see the potential benefits of the product and trust that it will only improve in later iterations.
• It provides a feedback loop that will help programmers improve the existing features and add new features with minimal delays.

Remember that the overall budget for the project is $350,000, and Third Avenue management would like to see a finished application available in four months. The MVP version, of course, must be available much more quickly—management wants it to be ready to ship in six weeks. The project team has decided that sprints will be done every two weeks, so the MVP version must be ready to ship for use and review after three sprint cycles. The budget for completing the MVP is $120,000.

Task 1 - Develop the project charter for the health-care app project.

Task 2 - Develop user stories and technical stories to describe the software requirements for the health-care app.

Task 3 - Develop an initial scope statement.

Because of management’s concerns about scheduling, they have requested that you add two members to your team:

• Aziz, a Quality Assurance tester who began his career as a programmer
• Barry, a member of Third Avenue’s three-person accounting staff

As the product owner, you have done some research on agile-specific scheduling and think that the scheduling approach used by the FBI to complete its Sentinel computerized file system will work for the Third Avenue project. This scheduling approach was discussed in Module 6. In the Sentinel project, work was organized into user stories, each of which were assigned a number of “story points” based on how much work was needed to complete each task. Story points are an abstract measure of the amount of effort needed to convert a user story into a functioning piece of software. Story points are calculated, or sized, based on the estimated amount of work needed, task complexity, risk in doing the work, and time required to do the work.

At the start of each two-week sprint, the team decided which user stories to complete for that sprint. Completed parts of the app were then incorporated into the next iteration of the software build for customer review and approval. User stories still pending completion were kept in the product backlog awaiting future sprints. This approach helped the team focus on completing a system that met customer requirements in a timely manner. The agile approach emphasizes finishing subsets of software features for the customer in regular, short intervals as opposed to an attempt to define and schedule the entire project at the beginning.

Management has also asked the team to develop a list of project milestones and make sure these can be completed within the sprint schedule, which is once every two weeks.

Task 4 - Prepare a Gantt chart for the health-care app project.

As with other methods of software development, the application’s size is a major indicator of how much it might cost to develop. In agile development, cost estimates are often made based on size measurements such as story points.

You will recall that each user story for the health-care app is assigned a number of story points based on estimates of how much work is needed to complete each major task. Based on prior experience with agile projects, the three-person accounting staff at Third Avenue Software has determined an average dollar production cost for a story point: $1200.

However, the staff accountants are not completely confident in this average dollar value because Third Avenue’s experience with agile projects is not extensive. The accountants would like the team to confirm their calculations, if possible.

Earned value management (EVM) is a more traditional project management method for determining whether a project is meeting time and cost goals. EVM requires calculation of three values for each major activity in the project:

• The planned value (PV), which is the authorized budget assigned to scheduled work
• The actual cost (AC), which is the realized cost for the work performed on an activity during a specified period of time
• The earned value (EV), a measurement of project work done, framed in terms of the approved budget for the work

Managers at Third Avenue are also eager to see evidence that the Quality Assurance staff are making progress in their ability to test the health-care app. They have asked the team to provide at least a basic framework of test specifications.

Task 5 - Prepare a Cost Analysis as described below.

1. Review the user stories, technical stories, and story points you developed in earlier parts of this case and then use the information to estimate the cost of the health-care app project. Third Avenue accountants estimate that the average production cost of a story point is $1200. Based on the values you calculate, do the project costs appear to be within the overall budget of $350,000? Do the costs seem to be within the MVP budget of $120,000? If the costs are not within budget, adjust the story points you developed in Part 3 to make sure your revised numbers are within budget. You might also have to reconsider the feature set within the MVP if it exceeds its budget.
2. Assume that you have completed one month of the health-care app project and have some reliable EVM data for cost accounting. Remember that the budget at completion (BAC) is $350,000 for the four-month project. You have received the following figures from the Third Avenue accountants:

PV         $105,000

EV         $122,000

AC         $105,000

Using this information, answer the following questions.

• What is the cost variance, schedule variance, cost performance index (CPI), and schedule performance index (SPI) for the project?
• Use the CPI to determine the estimate at completion (EAC) for the project.
• Based on your answers, does the project appear to be on schedule and within budget?

Task 6 -  Develop a short list of quality requirements for testing. Include at least five of the important app features and/or usability issues described thus far in this running case. In your list, briefly describe each requirement.

Task 7 - Develop a progress report for the project.

Task 8 - Develop a probability/impact matrix to document risks to the health-care app project.

Task 9 - Create a stakeholder management plan. Be sure to handle the stakeholders’ concerns and input for the health-care app after it has been released to the field. For example, continuing strategies are needed to monetize the software most effectively and to achieve maximum market penetration.

Task 10 - Create an issue log for the project’s main activities.

Answer 1

*****Please please please LIKE THIS ANSWER, so that I can get a small benefit, Please*****

SOLUTIONS: THIRD AVENUE SOFTWARE HEALTH-CARE APP PROJECT

Possible solutions for the assigned tasks in the Third Avenue health-care app project are shown in the following sections. Answers will vary for many of the solutions, as many tasks are open-ended and solicit students’ informed opinions based on their reading and understanding of the text and case.

One of the principal objects of task assignments in this case is to encourage students to examine differences between an agile approach and a more traditional approach to project management. If necessary, remind students that the following sections of the text focus on the agile approach:

· The “Agile” section, which begins in Module 2, introduces readers to agile concepts.

· The “Case Study 2” section of the Module 3 Reading describes a case in which agile principles are used.

· The last major section of the Modules 4 through 13 Readings describes “Considerations for Agile/Adaptive Environments.”

Possible Solutions for Part 1: Project Integration Management

1. The students’ answers will vary. Again, they are being asked to consider the project from an agile perspective, and their responses should reflect this.

Clearly, students should be expected to identify the first process of project integration management as necessary (“1. Develop the project charter”), because it is listed as the next task assignment. However, if some students feel that a charter is not necessary for an agile project and can provide reasonable justifications for their opinion, then their answers should be accepted.

Students will probably not identify the final process of project integration management as necessary (“7. Close the project or phase”), as the project is just beginning.

Students should probably include processes 2 through 6 as being necessary. Again, however, they can exclude processes as long as they provide solid justifications.

2. In this task, students were asked to develop a project charter. Again, answers will vary, but responses should be expected to resemble the sample project charter shown in Table 4-1 in Module 4. A possible project charter for the health-care app is shown below. Note that the project manager (known as the product owner in agile approaches) and project personnel have not yet been determined; some of them will be identified in Part 2 of the case. Note also that students are not required to create a project charter if they can provide a solid justification that agile projects do not require one.

SAMPLE PROJECT CHARTER

Project Title: Third Avenue Software Health-Care App Project

Date of Authorization: July 1

Project Start Date: July 8                      Projected Finish Date: [4 months from Start Date]

Key Schedule Milestones:

· Working versions will be released for review and testing well before the planned official release. [Students can provide sample dates if they wish.]

· A finished application should be available in four months from the beginning of the project.

Budget Information: Third Avenue’s total budget for this project is $350,000.

Project Manager: [This information is not yet available to students. It would be excellent if students could identify this role as “product owner,” which is the closest role to project manager in agile.]

Project Objectives: To use agile principles to produce the first best-selling product for Third Avenue.

Main Project Success Criteria: The project must contain working versions of the feature sets described in Part 1 of the case. The software must fulfill the usability requirements described in Part 1.

Approach:

1. Use agile and Scrum principles.

2. Release several working versions of software for review and testing.

3. The final version should be responsive to concerns expressed by all stakeholders.

Roles and Responsibilities: [As stated in the task assignment, project personnel have not been determined yet. Most personnel will be identified in Part 2.]

3. In agile approaches and Scrum, the closest role to that of project manager is product owner.

Skills and Qualities: Student answers should emphasize flexibility, responsiveness to change, the ability to adapt quickly, the ability to delegate responsibilities, and the ability to focus on individual interactions with stakeholders. All of these qualities are mentioned at various points in the text or are easy to extrapolate from an engaged reading of the text.

As for the task assignment of discussing how these skills and qualities differ in a Scrum approach versus that of a more traditional project management style, a good answer is shown in the “Scrum” section of Module 2 and repeated again here:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

4. A good summary of how the team will function is shown in the “Scrum” section of the Module 3 Reading. More information is provided in the “Case Study 2” section of the Module 3 Reading. A typical acceptable answer will include and explain terms such as product backlog, sprints, daily Scrums, and ScrumMaster. Good answers might also mention using an adaptive approach that is responsive to stakeholders. Answers can also incorporate discussion of the skills and qualities from Task 3.

5. Answers here could vary widely. Students should demonstrate that (a) they made a good-faith effort to at least find one app or online program that could be considered a competitor of the health-care app; and (b) they compared and contrasted the features in the app they found with the features described in Part 1. For example, newer versions of iPhones include a Health app.

6. As with possible answers to Task 4, a good summary of how agile and Scrum teams conduct meetings and run their schedules is shown in the “Scrum” section of the Module 3 Reading. More information is provided in the “Case Study 2” section of the Module 3 Reading. Acceptable answers will include terms such as product backlog, sprints, daily Scrums, and ScrumMaster. Good answers might also mention that several software iterations will have to be scheduled.

Possible Solutions for Part 2: Project Scope Management

1. In this task, students were asked to complete the project charter they began for a task assignment in Part 1 of the case, using the information they learned in Part 2. The finished project charter should include the following information:

· Roles and Responsibilities should include the list of project team members identified in Part 2, along with their descriptions.

· Budget Information should include a separate entry for the MVP version of the app; it has a budget of $120,000.

· Other sections of the project charter, such as Key Schedule Milestones, could be revised to include a description of the MVP version and other iterations of the app.

2. User stories are often written on index cards and then arrayed on a wall or table top to help the agile team plan how to implement the ideas into the product. Technical stories are then developed from the user stories. This approach facilitates group discussion, which often leads to a much better set of product specifications than the rather simple ideas expressed on the cards.

Students were given a high-level feature list for the health-care app and asked to develop a set of cards, user stories, and technical stories for those features. Here is an example of (1) a card that contains a user story for the fitness tracker planned to appear in the app; (2) a simple technical story based on the user story.

As a customer, I want to be able to keep track of my basic health and fitness information.

Fitness tracker

· The customer’s basic health and fitness information must be available in a separate window.

· This window must be easily accessible from the main window of the app.

· The window must contain entry fields for information such as blood pressure and cholesterol.

· These fields must allow for easy entry of health information.

3. Student replies will vary. As described in the task assignment, students must select a method for gathering requirements and then defend their selection in two paragraphs.

4. Students were asked to develop a sample scope statement. The following table shows typical components of a scope statement and sources that students can use to find information needed to complete the scope statement.

Component of scope statement	Sources of information
Information from the project charter	Students can add their answers from Part 2, Task 1
Product scope description	Students can incorporate information provided in Part 1
Functional and design specifications for developing software	Students can incorporate information they developed from their user stories and technical stories (in Part 2)
Product user acceptance criteria	Students can use information provided in this case and in Modules 3 and 5
Detailed information for project deliverables	Students can use information provided in this case and in Modules 3 and 5
Project boundaries, constraints, and assumptions	Students can use information provided in this case and in Modules 3 and 5
References to supporting documents, such as product specifications or corporate policies	N/A for this case

5. Student replies will vary. In the task assignment, students were asked to develop a list of features that would become the MVP for the first iteration of the health-care app.

Possible Solutions for Part 3: Project Schedule Management

1. Answers will vary based on the students’ user stories and technical stories, which serve as a basis for assigning story points. The assignment also advised students to examine complexity estimates of the major features in Part 1. Student assignments of story points should account for each major feature of the health-care app and should address usability issues in some manner as well. Here’s one possible answer.

· Fitness tracker for recording health information (e.g., blood pressure and cholesterol): 30 story points

· Medication tracker (“electronic pillbox”) with calendar and alarm notifications: 30 story points

· Electronic address book for contact data of doctors and other health-care professionals: 20 story points

· Emergencies list for storing vital phone numbers and addresses to provide quick access to hospitals, urgent care clinics, etc. List entries will trigger interactive GPS mapping software to help locate hospitals and other health-care venues: 60 story points

· Emergency information list in which customers store important data about themselves in case of emergency: 20 story points

· Resources feature that lists links to other popular online health sites: 10 story points

· Payment feature that tracks health expenses and allows customers to make payments through their phones: 40 story points

· Usability issues: 40 story points

2. Here is a possible schedule. Student answers should at least resemble this schedule. Students were advised in the task assignment that they could use scheduling freeware they downloaded from the Internet or could create the schedule using pen and paper.

ITEM                                                                                        DATE(S)

Project startup meeting                                                      July 8

Sprint 1         (each sprint = 2 weeks)                              July 8–July 21

        Initial planning / development of user stories      July 9–July 10

        Development of technical stories                             July 11

        Fitness tracker development                                      July 12–July 19

        Medication tracker development                              July 12–July 19

        Welcome Aziz & Barry                                                 July 18

Sprint 2                                                                                   July 22–August 4

        QA testing of fitness tracker                                      July 22–July 26

        QA testing of medication tracker                              July 22–July 26

        Initial development of emergencies list                  July 22–July 28

        Initial development of mapping feature                 July 29–August 4

Sprint 3                                                                                   August 5–August 18

        QA testing of emergencies list                                   August 5–August 9

        QA testing of mapping feature                                  August 5–August 9

        Development of resources feature                          August 5–August 9

        Initial development of payment feature                 August 10–August 14

        QA testing of resources feature                                August 10-August 13

        QA testing of payment feature                                 August 14–August 18

                                                                                                  Milestone (Aug. 18): Release MVP to field!

Note: This schedule does not show daily Scrum (“standup”) meetings.

3. Answers will vary. The object of the task is to reinforce the importance of constant reevaluation, continuous improvement, and adaptive planning in agile. The students’ answers should demonstrate understanding of this principle, as well as a basic understanding of an MVP.

4. Answers will vary. Student schedules should build off the schedules they created in Task 2. Schedule notations for the subsequent software iterations should use the same format and logic as notations used for the MVP version in Task 2.

5. Answers should resemble the sample schedule shown in Answer 2 above, reflect the information added in Answer 4, and resemble the example Gantt chart shown in Figure 3-6 (and below).

Possible Solutions for Part 4: Project Cost and Quality Management

1. The answer to both direct questions is Yes; the project costs should be within budget. Students were advised in the task assignment that they might have to adjust the story points they developed in Part 3 to make sure their numbers are within budget. They might also have to reconsider the feature sets they identified for the MVP if it exceeds its budget.

Answers will vary based on the students’ user stories and technical stories, which serve as a basis for assigning story points and then calculating production costs. The assignment also advised students to examine complexity estimates of the major features in Part 1. Student assignments of story points and production costs should account for each major feature of the health-care app and should address usability issues in some manner as well. Here’s one possible answer.

· Fitness tracker for recording health information (e.g., blood pressure and cholesterol): 30 story points × $1200 average production cost = $36,000

· Medication tracker (“electronic pillbox”) with calendar and alarm notifications:
30 story points × $1200 average production cost = $36,000

· Electronic address book for contact data of doctors and other health-care professionals: 20 story points × $1200 average production cost = $24,000

· Emergencies list for storing vital phone numbers and addresses to provide quick access to hospitals, urgent care clinics, etc. List entries will trigger interactive GPS mapping software to help locate hospitals and other health-care venues:
60 story points × $1200 average production cost = $72,000

· Emergency information list in which customers store important data about themselves in case of emergency: 20 story points × $1200 average production cost = $24,000

· Resources feature that lists links to other popular online health sites: 10 story points × $1200 average production cost = $12,000

· Payment feature that tracks health expenses and allows customers to make payments through their phones: 40 story points × $1200 average production cost = $48,000

· Usability issues: 40 story points × $1200 average production cost = $48,000

· Grand total: $300,000

2. Given a BAC of $350,000, a PV of $105,000, an EV of $122,000, and an AC of $105,000:

Cost variance = $17,000, schedule variance = $17,000, CPI = 1.162, and SPI = 1.162.

EAC = $301,205, which is very close to the grand total in the Task 1 solution.

Based on the preceding numbers, the project is on schedule and within budget.
The SPI and CPI are numbers above 1.

3. Student answers will vary. The task assignment included an example set of quality requirements for students to use as a guide.

4. Student answers will vary widely.

Possible Solutions for Part 5: Project Resource and Communications Management

1. Answers will vary, of course. The object of the task is to reinforce the importance of constant reevaluation, continuous improvement, and adaptive planning in agile. The students’ answers should demonstrate understanding of this principle.

2. Student answers should reflect one or both of the following points:

· One reason good communication is considered a strength of the agile approach is that the approach places such an emphasis on it. For example, agile projects have daily meetings to ensure all team members are on the same page. If the team can’t meet face to face, it can have virtual meetings instead.

· Project environments such as those in agile, which are subject to various elements of ambiguity and change, have an inherent need to communicate evolving and emerging details more frequently and quickly.

3. A sample progress report or status report is shown below. Remember that the items in the report should address project status in terms of scope, time, and cost.

SAMPLE PROGRESS REPORT

Project: Third Avenue Software Health-Care App Project

Team Member: Eric (ScrumMaster; [email protected])                 Date: August 21

Work completed this week:

· Fixed vague field names in the emergency information list

· Marketing work was finally completed for software iteration #2

· Confirmation from Accounting that the project is on budget

Work to be completed next week:

· Need to make fields easier to see throughout the app (i.e., heighten color contrast between fields and background)

· Need definite progress on marketing plan for software iteration #3

· Need to complete the bug fixes in the medical resources feature (which lists links to other popular online health sites) so that it is 100% complete

Work that is going well: Basic software development is proceeding according to plan. QA testing has yet to reveal any critical bugs, although there is a usual number of low-level defects.

Work that has impediments/issues:

· The marketing plans, as indicated above, are running behind. Brianna is aware of the problem, but she has other important responsibilities that require her time as well.

· Not a big problem, but need to double-check to make sure management is aware of daily meeting results, especially if those results contain important issues for fast resolution.

Suggestions:

· Is there a feasible way to outsource part of the marketing effort? Who can look into this question besides Brianna? Discuss with management.

· Remind programmers to discuss programming issues more robustly in the daily meetings. Eric and Lia sometimes huddle together in their cubes to work out quick solutions (which is fine!), but these solutions need to be communicated more effectively to the rest of the team.

Changes needed: Start giving higher priority to QA’s findings re the app’s usability. Programmers are focusing more on problems that can be fixed quickly via simple code revisions, which is expected, but usability issues can create larger sets of needed code revisions.

4. A sample burndown chart from Figure 3-7 in Module 3 is shown below.

Note: It is possible, although unlikely, that a student answered the Task 3 assignment above by providing a burndown chart. If so, no response is required for Task 4.

As discussed in Module 3, a burndown chart plots each day’s sum of estimated hours or points remaining. It also shows an idealized burndown line, as if the team were completing an equal amount of work each day (10 tasks each day in the chart shown). Most important, the chart displays how well the team is doing in a particular sprint; for example, it can indicate that some user stories might not be completed during the sprint, and thus should be held until the next sprint. On the other hand, a chart that indicates better than expected progress could lead to stories being added to the sprint.

Possible Solutions for Part 6: Project Risk and Procurement Management

1. Agile environments can carry higher risks than traditional project management environments because agile uses a dynamic approach that is subject to quickly changing circumstances and high variability. By definition, such an environment leads to greater uncertainty and risk than one that requires more extensive upfront planning. To address this issue, agile projects require more iterations of product work (software, in Third Avenue’s case) to help uncover potential risks and resolve them more quickly.

2. A sample risk register and a sample probability/impact matrix are shown below. Students were given the option of developing one or the other.

A risk register can take the format and contain the headings shown in Table 11-4 and reproduced here:

Here is an example of a full entry in the risk register shown above. This entry addresses the risk mentioned in Part 6 of the case:

The health-care app should appeal to an older audience than customers who download and buy the majority of mobile apps. Therefore, the issue of usability is crucial, as older users are often not as tech-savvy as their younger counterparts. This issue could create some profound market risks if the app’s usability features are not well conceived and executed.

· No.: R44 is an internal tracking number within Third Avenue.

· Rank: 1. Rankings can range from 1 to x, with 1 being the highest risk ranking.

· Risk: Usability of app (general)

· Description: It is generally accepted that apps with appeal to older demographic segments must be easier to use and navigate.

· Category: Market risk

· Root cause: Older users are often not as technologically knowledgeable and adept as younger users.

· Triggers: Third Avenue hired an elderly couple who agreed to test the MVP version of the app. Their findings were mixed.

· Potential responses: Brianna in Marketing and at least two programmers on the project should meet with the couple and review their findings together.

· Risk owner: Product owner

· Probability: Medium

· Impact: High

· Status: This issue was addressed in the first three daily Scrums. Address again in tomorrow’s meeting to make sure the team is on the same page.

Students were also given the option of developing a probability/impact matrix. A sample matrix from Figure 11-5 in Module 11 is shown below.

If students submit a probability/impact matrix, they of course must explain the risks indicated and demonstrate an understanding of how the matrix works. For example, the lowest risks are those with both a low probability of occurrence and a low impact if they do occur. Such risks are shown in the lower-left corner of the matrix. The highest risks (1 and 4 in this example), shown in the opposite corner, have both a high probability of occurrence and a high impact if they do occur.

3. Answers will vary, of course. The object of the task is to reinforce the importance of constant reevaluation, continuous improvement, and adaptive planning in agile. The students’ answers should demonstrate understanding of this principle.

4. Again, answers here can vary widely. The object of the task is to ensure that students have an adequate understanding of the concepts of procurement and outsourcing. For example, students could argue that Brianna, the marketing rep for the health-care app project, needs outside assistance to keep the project’s marketing milestones on schedule. (Third Avenue Software has a very small marketing staff—Brianna and a part-time intern.) Students could also argue that no outsourcing is needed, which of course is the easiest answer to this task assignment, but they need to provide adequate justification. For example, students who argue that no outsourcing is needed should explain that the project is on track when evaluated in terms of the triple constraint—meeting scope, time, and cost goals.

Possible Solutions for Part 7: Project Stakeholder Management

1. Customers are the missing group of stakeholders.

2. Answers could vary widely here. Good answers will mention that agile and Scrum take an adaptive approach that is responsive to stakeholders. The approach also emphasizes individuals and interactions over processes and tools, customer collaboration over contract negotiation, and responsiveness to change.

3. In this task, students were asked to develop a stakeholder management plan. Enterprising students will follow the form of the sample plan shown in Module 13, Table 13-2. It is acceptable for students to leave some columns blank (for example “Power/Interest,” as long as they justify their decisions by explaining why the columns do not apply to agile principles. One possible plan for the health-care app project is shown below.

SAMPLE STAKEHOLDER MANAGEMENT PLAN

Name	Power/Interest	Current Engagement	Potential Management Strategies
The student [product owner]	High/high	Leading	[He/She] seems ideal for the role of product owner: Flexible, always upbeat, communicates well. Doesn’t let own programming experience and expertise interfere with the other programmers’ work.
Brianna	High/high	Unaware	Brianna is an excellent marketer. That and her experience in health care make her a valuable part of the team, but she is stretched thin right now. This is convention season, and she is also working hard to increase the visibility of other Third Avenue apps.
Eric	High/high	Resistant	Eric’s programming skills are unquestioned, but he is sometimes too possessive of his work and too defensive if it is criticized even gently. He needs occasional reminders that the app’s success is a team goal.
Aziz	High/high	Supportive	His work as QA tester is outstanding. He has experience in programming, so he knows how to frame concerns with the app in a way that will engage programmers rather than alienate them.

4. In this task, students were asked to create an issue log. Enterprising students will follow the form of the sample issue log shown in Module 13, Table 13-4. It is acceptable for students to leave some columns blank, as long as they justify their decisions by explaining why the columns do not apply to agile principles. One possible abbreviated issue log for the health-care app project is shown below.

SAMPLE ISSUE LOG

Description	Impact	Date Reported	Reported By	Assigned To	Priority (H/M/L)	Due Date	Status	Comments
Phone number fields allow alphabetic characters	Important	Aug. 20	The student [product owner]	Lia	H(igh)	Aug. 27	Closed	s/b easy fix, but needed ASAP
Marketing input must be more timely	Important	Aug. 23	Eric (Scrum-Master)	Brianna	H(igh)	Sept. 1	Open	Brianna is away at 2 sales conventions; has been apprised of issue
Etc. …

*****Please please please LIKE THIS ANSWER, so that I can get a small benefit, Please*****