MGMT 651 Week 7 Agile Project Plan: Final Example

Agile Project Plan: A Bilingual Appointment Reminder and Telehealth Check-In App for a Community Health Center

Introduction

The health center serves about 14,000 patients at three clinics in a mostly rural county, and more than half of its patients rely on Medicaid or pay on a sliding scale without coverage. In the past year, 22 percent of scheduled appointments were missed, and the telehealth program, which grew quickly during the pandemic, loses about one visit in six when patients cannot find or open the visit link. A twelve-month grant from a state health foundation will fund a mobile app, in English and Spanish, that reminds patients of appointments, lets them confirm, cancel or reschedule, and checks them in for telehealth visits with a single tap. This plan describes how the app will be built using Scrum, with a small contracted development team working in two-week sprints alongside the center's staff and patients. It sets out the business case, the reasons for an agile approach, the team and stakeholders, the product backlog, estimation and release planning, the sprint routine, quality standards, metrics, risks, the care of the team and a biblical perspective on the work.

Background and Business Case

Missed appointments carry costs for patients and for the center. For patients, they delay follow-up for long-term illnesses, blood sugar and blood pressure control above all, which make up a large share of the center's visits. For the center, each missed visit is an hour of clinician time that cannot be billed and that another patient could have used. At the center's current volumes, the 22 percent no-show rate represents roughly 11,000 lost visits a year.

Research supports reminders as a remedy. Pooling trials of phone text reminders for health visits, the Cochrane team of Gurol-Urganci et al. (2013) found more patients kept their appointments when texted than when not reminded at all, and about as many as when staff phoned them, at a fraction of the staff time. The center currently relies on staff phone calls made the day before, and calls reach only about half of patients. Telehealth adds a second reason for the app. Surveying forty-four studies of how patients rate telehealth, Kruse et al. (2017) found that patients often valued telehealth for improved outcomes, ease of use and convenience, which suggests that removing the friction of joining a visit could keep patients in care. The grant's goal is measurable: reduce the no-show rate to 15 percent and raise the share of scheduled telehealth visits that start successfully from 83 to 95 percent within six months of launch.

Why an Agile Approach

The project's characteristics point toward an agile approach. Boehm and Turner (2003) recommend balancing agile and plan-driven methods according to risk, considering factors such as size, criticality, the dynamism of requirements, personnel and culture. This project is small, a team of seven building one app; its criticality is moderate, since reminders support care but do not deliver it; and its requirements are likely to change once patients use early versions, especially around language, reading level and how patients with limited data plans use the app. In a cross-industry sample of roughly a thousand projects, Serrador and Pinto (2015) found that projects leaning harder on agile practice tended to do better on efficiency and on stakeholder satisfaction, while also finding that planning before execution still mattered.

The evidence for agile is not uniform. Reviewing the empirical record on agile development, Dybå and Dingsøyr (2008) rated the strength of evidence as low and noted that most studies examined single methods in particular settings. The plan therefore combines Scrum for the app's development with fixed grant milestones: quarterly reports to the foundation, a launch date by month seven and an evaluation at month twelve. Organizations beyond software, according to Conforto et al. (2014), commonly reshape agile into blended models, and this plan is one of them. The grant's milestones keep the project life cycle that Gido et al. (2018) describe, from initiation to closing, in view while the work inside it proceeds in sprints.

Product Vision, Goal and Scope

The product vision is a simple statement: every patient knows when the next visit is, can change it without a phone call and can join a telehealth visit in one tap, in the language the patient prefers. The product goal for the grant year is a launched app, used by at least 40 percent of active patients, that reduces no-shows and failed telehealth starts to the targets in the business case.

The scope includes text and app reminders, confirmation and cancellation, rescheduling into open slots, telehealth check-in, a staff dashboard showing confirmations, and integration with the center's practice management and telehealth systems. It excludes clinical messaging between patients and providers, prescription refills and bill payment, which the center may add later, and it excludes changes to the scheduling system itself.

The Scrum Team and Roles

The Scrum Guide describes a Scrum team of one product owner, one Scrum master and developers, self-managing and accountable together for creating a valuable increment each sprint (Schwaber & Sutherland, 2020). The product owner is the center's director of patient access, who knows the scheduling process and has the authority to order the backlog. The Scrum master is the center's project manager, trained in Scrum and responsible for the team's effectiveness and for removing obstacles. The developers are five people from a contracted firm: two mobile developers, a back-end developer for integration, a tester and a designer with experience in plain-language and bilingual design.

Hoda et al. (2013) traced self-organization to unofficial parts that members take up as the work demands, among them someone who carries meaning between the business and the technical side, and someone who coaches the others in agile habits. The plan assigns no one these roles but expects them to emerge, and the Scrum master will encourage them: the front desk supervisor, who attends backlog refinement, is likely to act as translator, and the contractor's lead developer as mentor for the center's staff. Moe et al. (2010), following one Scrum team closely, saw shared responsibility erode when members kept to their own specialties, so the plan asks developers to pair across specialties on each sprint's highest-priority story.

Stakeholders

Assumptions and Constraints

The plan assumes that the practice management vendor will provide access to its scheduling interface by the end of the first sprint, that at least 70 percent of active patients have a mobile phone that receives texts, that the patient advisory council can supply two advisors for each sprint review, and that the contracted team will remain stable for the twelve sprints. It is constrained by the grant's twelve-month term and fixed budget, by federal privacy rules for protected health information, by the center's requirement that all patient-facing text be available in English and Spanish, and by the clinics' operating hours, since staff can join refinement and reviews only during slower afternoon periods. If any assumption fails, the Scrum master will raise it at the next sprint review and the product owner will adjust the backlog.

Budget

The largest cost is the development team, priced per sprint, which allows the center to stop or redirect the work at any sprint boundary if outcomes do not justify continued spending. Contingency covers unexpected integration work or a thirteenth sprint if velocity falls short.

Product Backlog

The product backlog is organized into four epics: reminders and confirmations, rescheduling, telehealth check-in, and the staff dashboard. User stories follow the form Cohn (2004) describes, a short statement of a need from a user's point of view that serves as a promise of later conversation, with acceptance criteria that define when the story is done.

A literature review on agile requirements work by Inayat et al. (2015) lists the neglect of nonfunctional requirements as a recurring challenge, so the backlog includes explicit stories for privacy and security of health information, accessibility for patients with low vision, performance on low-cost phones and translation review by bilingual staff. The product owner orders the backlog by value to patients and by risk, with the telehealth integration placed early because it carries the greatest technical uncertainty.

Estimation and Release Planning

The team will estimate the backlog in story points using planning poker, in which each member chooses an estimate privately, reveals it at the same time and discusses differences until the team agrees. Moløkken-Østvold et al. (2008) reported that consensus estimates from planning poker came out both more cautious and closer to actual effort than averaged individual guesses, in part because the talk uncovered forgotten tasks. The review by Jørgensen (2004) supports relying on the judgment of experienced estimators, provided several of them are consulted and optimism is checked. The initial backlog is estimated at 288 points.

Cohn (2006) describes release planning as dividing the remaining backlog by the team's measured velocity to forecast the number of sprints. The plan assumes a velocity of 24 points per two-week sprint, based on the contractor's recent similar work, and will replace the assumption with measured velocity after three sprints.

With 288 points and a velocity of 24, the forecast is twelve sprints, or six months, leaving months seven to twelve for adoption, support and the grant's outcome evaluation. If measured velocity falls below 20 points, the product owner will move lower-value stories from release 3 to a later phase rather than extend the release dates, so that the grant's launch milestone holds.

Sprint Cadence and Events

Each sprint lasts two weeks. Sprint planning, held on the first Monday morning, sets a sprint goal and selects backlog items the developers forecast they can complete. The daily scrum, fifteen minutes each morning, lets developers inspect progress toward the sprint goal and adjust their plan. Backlog refinement, held weekly for an hour, adds detail and estimates to upcoming stories with the front desk supervisor present. The sprint review, on the last Thursday, demonstrates the increment to stakeholders, including two patient advisors, and gathers feedback that updates the backlog. The retrospective, held the same afternoon, examines how the team worked and chooses one improvement for the next sprint. Takeuchi and Nonaka (1986), whose description of overlapping, team-based product development gave Scrum its name, emphasized that teams learn through such repeated cycles of action and reflection.

Definition of Done and Quality

The Scrum Guide defines the definition of done as a formal description of the state of an increment when it meets the quality measures required for the product (Schwaber & Sutherland, 2020). For this app, a story is done when its acceptance criteria pass automated and manual tests; it works on the three most common phone models among the center's patients; English and Spanish text have been reviewed by bilingual staff; the reading level is grade six or lower; it passes the privacy checklist for protected health information; and two patient advisors have used it in the sprint review without help. Work that does not meet the definition returns to the backlog and is not counted toward velocity.

Metrics and Benefits Tracking

The team will track delivery and outcome measures. Delivery measures include velocity, a release burn-up chart showing points completed against the release scope, and the number of stories returned for failing the definition of done. Outcome measures follow the business case: the no-show rate, the share of telehealth visits that start successfully, the percentage of active patients using the app and patient satisfaction from a three-question survey after each release. The product owner will report outcome measures to the board monthly from the first release, so that later sprints can respond to what the measures show.

Risk Management

Training and Adoption

An app that patients do not install cannot reduce no-shows, so adoption is planned alongside development. Front desk staff will be trained before each release, with a one-page guide in both languages and a script for inviting patients during check-in. Each clinic will display a poster with a code patients can scan to install the app, and staff will offer to set it up on the patient's phone while the patient waits. Patients who prefer not to install the app will still receive text reminders and can confirm or reschedule by reply, so the most important benefit reaches patients with older phones. The product owner will review adoption figures weekly after the first release and ask the team to address any step where patients commonly stop, such as account creation.

Governance and Reporting

The executive director chairs a monthly steering meeting with the product owner, the Scrum master and the medical director, which reviews the release burn-up chart, outcome measures and risks, and approves any change to release dates or the budget. Quarterly reports to the foundation are timed to follow releases, so that each report can show a working increment and its early results. Decisions about the product's content remain with the product owner, consistent with the Scrum Guide, while the steering meeting owns decisions about money and dates.

Team Health and Collaboration

Agile methods depend on teamwork, and the plan treats the team's health as a deliverable. Lindsjørn et al. (2016), linked the quality of teamwork in 71 agile teams to how well members and team leads judged the team to perform, and still more strongly to what members learned and how much they enjoyed the work. The Scrum master will use retrospectives to monitor communication, mutual support and balance of contributions, and will pay particular attention to the boundary between the contracted developers and the center's staff, who come from different organizations with different habits. Shared sprint reviews with patients are intended to give both groups a common purpose that neither contract nor job description supplies.

Scaling and Organizational Change

If the app succeeds, the center plans to extend the approach to other projects, such as an online intake form. Dikert et al. (2016), reviewing large-scale agile transformations in 42 industrial cases, found that most reports were experience reports and identified challenges such as resistance to change, coordination among teams and the difficulty of fitting agile into existing structures. The center is small enough to avoid most of these, but the plan recommends a review at month twelve before any second agile project begins, so that lessons from this one shape the next.

Biblical Integration

The project's purpose is care for neighbors who face barriers to health care. Jesus described the righteous as those who fed the hungry, welcomed the stranger and visited the sick, and said that whatever was done for the least of his brothers was done for him (English Standard Version Bible, 2001/2016, Matthew 25:35-40). Many of the center's patients are exactly those whom the passage describes: low-income families, immigrants and older adults living alone. An app that helps them keep appointments in their own language is a modest but real form of that care.

The project also involves stewardship of money given for a purpose. Paul wrote that a steward's first qualification is trustworthiness (English Standard Version Bible, 2001/2016, 1 Corinthians 4:2). The plan's measures, honest forecasts and quarterly reports to the foundation are ways of being faithful with grant funds. Agile methods, with their short cycles of building, showing and listening, fit a ministry of care because they keep the people being served in the room while the work is done.

Conclusion

This plan sets out how a small Scrum team will build a bilingual reminder and telehealth check-in app in twelve two-week sprints, within a twelve-month grant. It grounds the business case in evidence on text reminders and telehealth, justifies a hybrid of Scrum and fixed grant milestones, defines the team and stakeholders, orders a product backlog of user stories with explicit nonfunctional requirements, forecasts three releases from estimated points and velocity, and sets a definition of done, metrics and risk responses. If the app reaches its targets, the center will see fewer missed visits and fewer lost telehealth appointments, and its patients will find it easier to stay in care.

References

Boehm, B., & Turner, R. (2003). Using risk to balance agile and plan-driven methods. Computer, 36(6), 57-66. https://doi.org/10.1109/MC.2003.1204376

Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley.

Cohn, M. (2006). Agile estimating and planning. Prentice Hall.

Conforto, E. C., Salum, F., Amaral, D. C., da Silva, S. L., & de Almeida, L. F. M. (2014). Can agile project management be adopted by industries other than software development? Project Management Journal, 45(3), 21-34. https://doi.org/10.1002/pmj.21410

Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software, 119, 87-108. https://doi.org/10.1016/j.jss.2016.06.013

Dybå, T., & Dingsøyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9-10), 833-859. https://doi.org/10.1016/j.infsof.2008.01.006

English Standard Version Bible. (2016). Crossway. (Original work published 2001)

Gido, J., Clements, J., & Baker, R. (2018). Successful project management (7th ed.). Cengage Learning.

Gurol-Urganci, I., de Jongh, T., Vodopivec-Jamsek, V., Atun, R., & Car, J. (2013). Mobile phone messaging reminders for attendance at healthcare appointments. Cochrane Database of Systematic Reviews, 2013(12), Article CD007458. https://doi.org/10.1002/14651858.CD007458.pub3

Hoda, R., Noble, J., & Marshall, S. (2013). Self-organizing roles on agile software development teams. IEEE Transactions on Software Engineering, 39(3), 422-444. https://doi.org/10.1109/TSE.2012.30

Inayat, I., Salim, S. S., Marczak, S., Daneva, M., & Shamshirband, S. (2015). A systematic literature review on agile requirements engineering practices and challenges. Computers in Human Behavior, 51, 915-929. https://doi.org/10.1016/j.chb.2014.10.046

Jørgensen, M. (2004). A review of studies on expert estimation of software development effort. Journal of Systems and Software, 70(1-2), 37-60. https://doi.org/10.1016/S0164-1212(02)00156-5

Kruse, C. S., Krowski, N., Rodriguez, B., Tran, L., Vela, J., & Brooks, M. (2017). Telehealth and patient satisfaction: A systematic review and narrative analysis. BMJ Open, 7(8), Article e016242. https://doi.org/10.1136/bmjopen-2017-016242

Lindsjørn, Y., Sjøberg, D. I. K., Dingsøyr, T., Bergersen, G. R., & Dybå, T. (2016). Teamwork quality and project success in software development: A survey of agile development teams. Journal of Systems and Software, 122, 274-286. https://doi.org/10.1016/j.jss.2016.09.028

Moe, N. B., Dingsøyr, T., & Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology, 52(5), 480-491. https://doi.org/10.1016/j.infsof.2009.11.004

Moløkken-Østvold, K., Haugen, N. C., & Benestad, H. C. (2008). Using planning poker for combining expert estimates in software projects. Journal of Systems and Software, 81(12), 2106-2117. https://doi.org/10.1016/j.jss.2008.03.058

Schwaber, K., & Sutherland, J. (2020). The Scrum guide: The definitive guide to Scrum: The rules of the game. https://scrumguides.org/

Serrador, P., & Pinto, J. K. (2015). Does agile work? A quantitative analysis of agile project success. International Journal of Project Management, 33(5), 1040-1051. https://doi.org/10.1016/j.ijproman.2015.01.006

Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business Review, 64(1), 137-146.