PM FPX 4080 Assessment 5 The Sprint

PM FPX 4080 Assessment 5 The Sprint

Name

Capella University

PM-FPX 4080 Agile Project Management

Prof. Name

Date

PM FPX 4080 Assessment 5 The Sprint

Introduction

Sprint planning is an essential part of Agile project management because it helps teams define short-term goals, prioritize development tasks, assign responsibilities, and measure progress toward a working product. In PM FPX 4080 Assessment 5, the CapraTek Alfred thermostat project demonstrates how a Scrum team can use sprint planning, a product backlog, a burndown chart, and a clear Definition of Done to develop an iOS application that improves customer engagement and supports retention.

The project focuses on creating a mobile application that allows customers to control their Alfred smart thermostats, customize dashboard settings, review energy usage trends, and receive notifications about energy efficiency. The team’s primary business objective is to increase customer retention by 20% through improved functionality and a more convenient user experience. Achieving this goal requires collaboration between developers, project leadership, and stakeholders, along with realistic task estimates and consistent quality assurance.

This sprint plan identifies the sprint goal, outlines the development backlog, defines Scrum roles and responsibilities, and explains how burndown tracking and completion criteria can help the team manage progress. It also considers how unexpected absences and mandatory training may affect the sprint schedule.

Part 1: Sprint Plan

Sprint Goal and Project Objectives

The primary goal of the CapraTek Alfred sprint is to develop essential mobile application features that improve the customer experience and support a targeted 20% increase in customer retention. Previous Alfred product initiatives reportedly struggled to generate sufficient profitability, revenue, and customer engagement. Limited compatibility with mobile applications was identified as an important product limitation, creating an opportunity to improve the customer experience through mobile connectivity.

The team aims to develop an iOS application that allows customers to control their thermostats conveniently from their mobile devices. The application should provide secure access, an intuitive dashboard, customizable display preferences, energy usage trends, and notifications that help customers make informed decisions about their energy consumption.

The sprint goal gives the development team a shared purpose while connecting individual tasks to broader business objectives. Instead of focusing only on completing technical work, the team must consider whether each feature contributes to usability, reliability, security, and customer satisfaction.

PM FPX 4080 Assessment 5 The Sprint

The primary sprint objectives include developing a secure iOS login process, creating a dashboard for thermostat settings, allowing users to customize dashboard preferences, and implementing notifications related to energy efficiency. The team must also establish stable Wi-Fi connectivity and test communication between the mobile application and the thermostat.

Although the 20% retention increase is the project’s business target, it should be measured over an appropriate period using customer retention data. A single sprint cannot establish whether the target has been achieved. The team should therefore track leading indicators, such as application usability, feature adoption, customer feedback, and successful thermostat connections, while monitoring retention over time.

Sprint Backlog and Task Prioritization

A sprint backlog translates the product vision into specific development tasks that the team can complete during a defined period. For the Alfred thermostat project, tasks were prioritized according to their importance to security, user experience, energy efficiency, and the successful delivery of the mobile application.

The initial backlog contains four high-priority work items. Each item includes an identifier, estimated effort, planned dates, and a status. These details help the Scrum team coordinate development, identify dependencies, and monitor progress throughout the sprint.

Sprint Task Breakdown

Task ID Task description Estimated effort Priority Planned start Planned end Status
100-013 Implement password-protected iOS security, secure key generation and storage, and dedicated email-related configuration 160 hours High February 14, 2022 March 11, 2022 Started
100-001 Develop the dashboard interface for viewing thermostat settings, including database implementation and middleware development 80 hours High February 14, 2022 February 25, 2022 Complete
100-002 Create customizable dashboard interfaces and preferences for displaying thermostat and usage trends 160 hours High February 28, 2022 March 18, 2022 In progress
100-009 Develop energy-efficiency alerts and notifications, including backend software, notification logic, static code analysis, and enhancements 96 hours High March 1, 2022 March 16, 2022 Not started

Note: The dates and task estimates reflect the supplied project scenario. The original task table contains inconsistent column alignment, so the task estimates and status information should be verified against the official project backlog before submission.

Task 100-013: iOS Security Configuration

The first task focuses on protecting the Alfred application through password-based login and secure management of authentication-related information. The estimated effort is 160 hours, reflecting the work required to configure security settings, generate and store keys securely, and establish the required email-related configuration.

Security is a fundamental requirement for connected smart-home products because unauthorized access could compromise customer privacy or allow unwanted changes to thermostat settings. The development team should follow secure coding practices, validate authentication behavior, and verify that sensitive information is protected during storage and transmission.

The task should not be considered complete merely because the login screen works. The team must also test authentication failures, unauthorized access attempts, secure key handling, and relevant error conditions.

Task 100-001: Thermostat Dashboard Development

The dashboard task focuses on creating an interface through which users can view their thermostat settings. The work includes database implementation, middleware development, and integration of thermostat settings into the application.

The dashboard is a central part of the customer experience because it allows users to understand and manage their smart thermostat without navigating complicated menus. An intuitive interface can reduce user frustration and encourage continued engagement with the Alfred product.

The original backlog estimates 80 hours for this task and marks it as complete. Before accepting the item, the team should confirm that the dashboard displays accurate information, communicates correctly with the thermostat, handles connectivity failures, and performs reliably across supported iOS devices.

Task 100-002: Customizable Dashboard and Usage Trends

The second dashboard task expands the application’s functionality by allowing customers to personalize their dashboard and review relevant usage trends. The estimated effort is 160 hours and includes additional database interfaces, dashboard development, and coding for user preferences.

Customization can improve usability by allowing customers to display information that matters most to them. Usage trends can also help customers understand their heating and cooling patterns and make more informed decisions about energy consumption.

The team should validate that preferences are saved correctly, trends are displayed accurately, and dashboard changes do not interfere with existing thermostat controls. The user interface should remain accessible and understandable for customers with different levels of technical experience.

Task 100-009: Energy-Efficiency Alerts and Notifications

The notification task involves developing backend functionality, coding alerts, performing static code analysis, and implementing enhancements. The estimated effort is 96 hours.

Notifications can help customers understand energy-related activity and identify opportunities to adjust thermostat settings. To remain useful, alerts should be timely, relevant, and configurable. Excessive or unclear notifications could frustrate users and reduce engagement, so the team should consider notification frequency and customer preferences during development.

Testing should confirm that notifications are triggered under the correct conditions, display accurate information, and behave appropriately when the application is running in the background or the device temporarily loses connectivity.

Scrum Roles and Responsibilities

Scrum defines specific accountabilities that help teams organize work, make decisions, and deliver value through iterative development. In the CapraTek Alfred project, Rachel Davis is assigned the Scrum Master role, while Darren Stokes is assigned the Product Owner role. Other stakeholders and technical specialists contribute to the development work as members of the project team.

Rachel Davis: Scrum Master

Rachel Davis, the Smart Home Technologies Project Manager, serves as the Scrum Master. Her responsibilities include facilitating Scrum events, helping the team understand and follow Scrum practices, identifying obstacles, and promoting effective collaboration.

Rachel will coordinate daily stand-up meetings, monitor progress against the sprint goal, and help resolve issues that prevent team members from completing their work. She will also support communication between the development team and stakeholders so that project concerns can be addressed promptly.

The Scrum Master should focus on enabling the team rather than directing every technical decision. By encouraging transparency, collaboration, and continuous improvement, Rachel can help the team maintain a realistic workload and respond effectively to unexpected challenges.

Darren Stokes: Product Owner

Darren Stokes serves as the Product Owner. His experience with previous Alfred products provides useful context about customer expectations, product limitations, and opportunities for improvement.

Darren is responsible for maximizing product value by maintaining and prioritizing the product backlog. He should clarify requirements, establish acceptance criteria, and ensure that the team understands the purpose of each backlog item. His decisions should reflect customer needs, business objectives, technical considerations, and stakeholder feedback.

At the end of the sprint, Darren should review the completed work against the agreed acceptance criteria and provide feedback. This review helps determine whether the delivered functionality meets the intended requirements and whether backlog items need refinement before a future sprint.

Development Team and Stakeholder Collaboration

Developers, software architects, testing specialists, and other relevant stakeholders collaborate to complete the sprint backlog. The team is responsible for estimating the work, developing and testing the features, identifying dependencies, and maintaining product quality.

Daily communication is especially important when tasks depend on one another. For example, dashboard development may rely on database functionality, while notifications may depend on backend services and reliable communication with the thermostat.

The team should raise blockers early, coordinate testing activities, and ensure that each completed feature meets the agreed Definition of Done. This shared responsibility reduces the risk of unfinished work being treated as ready for release.

Sprint Burndown Chart and Progress Tracking

A sprint burndown chart is an Agile project management tool that shows how much work remains during a sprint. It typically compares the remaining estimated effort with the time available, allowing the team to identify whether progress is consistent with the sprint plan.

For the Alfred project, the sprint is described as a 22-day period. The team should use the burndown chart to track remaining backlog effort, review daily progress, and identify obstacles that may threaten the sprint goal.

The horizontal axis generally represents the days of the sprint, while the vertical axis represents the remaining work, measured in hours or story points. A reference line can show the expected rate of progress, while actual daily values show how much work remains.

When the actual burndown line stays above the expected line, the team may be completing work more slowly than planned. If it falls below the expected line, the team may be progressing faster than anticipated. Neither pattern automatically proves that the sprint will succeed or fail; the team must consider task complexity, quality, dependencies, and changes in scope.

The supplied project information does not include daily remaining-work values, so an accurate numerical burndown chart cannot be reconstructed from the task list alone. To produce the chart, the team needs an initial effort estimate and daily records of completed and remaining work.

Definition of Done for the Alfred Sprint

The Definition of Done establishes the quality requirements that must be satisfied before work can be considered complete. It creates a shared understanding among developers, testers, the Product Owner, and other stakeholders about what constitutes a finished product increment.

For the Alfred thermostat sprint, a backlog item should not be marked complete simply because the code has been written. The feature must meet its acceptance criteria, pass the required testing, and integrate successfully with the application.

The sprint’s Definition of Done should include the following requirements:

  • Password-protected login and applicable security controls function correctly.

  • The dashboard displays accurate thermostat settings.

  • Dashboard preferences and usage trends work as intended.

  • Energy-efficiency notifications are triggered under the correct conditions.

  • Code reviews and static code analysis are completed.

  • Unit and functional tests pass according to established acceptance criteria.

  • Relevant integration and performance testing is completed.

  • Identified defects that prevent acceptance are corrected and retested.

  • The feature is documented and integrated into the agreed product build.

PM FPX 4080 Assessment 5 The Sprint

Testing should include appropriate single-user performance checks, connectivity scenarios, and error handling. Security-related features should receive specific attention because weaknesses in authentication or key management can affect the entire product.

The team should also distinguish between completing a sprint and releasing software to customers. A product increment can satisfy the Definition of Done without being immediately released, depending on the organization’s release process and approval requirements.

According to the Agile Alliance’s guidance on the Definition of Done, shared completion criteria help teams maintain consistent quality and avoid treating unfinished work as completed work. Work that fails to meet the agreed criteria should remain incomplete and be reconsidered during backlog planning.

Daily Stand-Up Meetings and Continuous Improvement

Daily stand-up meetings provide a regular opportunity for team members to discuss progress toward the sprint goal, identify blockers, and coordinate immediate work. These meetings should be brief and focused on information that helps the team plan its next steps.

During the Alfred sprint, developers can report progress on security configuration, dashboard functionality, and notification development. Testing specialists can identify failed tests or defects that require developer attention, while the Scrum Master can help address obstacles that affect multiple team members.

The team should avoid using daily stand-ups solely as status reports to management. Instead, the meeting should encourage collaboration and help team members adjust their work based on current conditions.

At the end of the sprint, the team should review what was completed, gather stakeholder feedback, and identify improvements for the next iteration. This process may reveal that estimates need adjustment, testing should begin earlier, or dependencies should be clarified before work starts.

Part 2: Updated Burndown Chart

Adjusting the Sprint Plan for Unexpected Absences

The updated burndown plan accounts for a team member’s illness and unexpected mandatory training. These events reduce the team’s available working capacity and may affect task completion, particularly when the absent person is responsible for specialized work or tasks that other team members cannot immediately take over.

The scenario indicates that the team still has one day of schedule flexibility. This buffer may help accommodate the disruption, but the project manager and Scrum Master should verify whether the remaining work can realistically be completed without compromising the Definition of Done.

The team should reassess the outstanding tasks, identify dependencies, and determine whether work can be redistributed safely. Tasks that require specialized knowledge may need additional support, while lower-priority work may need to remain in the product backlog for a future sprint.

A burndown chart should reflect actual remaining work rather than being adjusted simply to make progress appear on schedule. If the team’s capacity changes, the chart should show the updated position, and stakeholders should be informed when the sprint goal or delivery expectations are at risk.

Recommended Actions for Sprint Recovery

The Scrum Master and Product Owner can work with the team to:

  • Recalculate available capacity after accounting for illness and mandatory training.

  • Review the remaining backlog and prioritize work that directly supports the sprint goal.

  • Identify tasks that can be reassigned without introducing unacceptable quality or security risks.

  • Resolve blockers and dependencies that could delay completion.

  • Update the burndown chart using actual remaining-effort estimates.

  • Communicate any necessary scope or schedule adjustments to stakeholders.

  • Preserve the Definition of Done instead of declaring incomplete work finished.

If the team cannot complete every planned backlog item, it should focus on delivering the highest-value work that satisfies the agreed quality criteria. In Scrum, the sprint goal provides direction, but it does not justify bypassing testing or accepting unfinished functionality.

Evaluating the Updated Burndown Chart

The updated burndown chart should show the effect of reduced team capacity and the subsequent recovery actions. A temporary slowdown may cause the actual remaining-work line to stay above the expected line. If the team resolves blockers or redistributes work effectively, the remaining-work trend may improve during the final days.

However, having one day of schedule flexibility does not guarantee that the sprint will finish successfully. The result depends on the amount of work remaining, task dependencies, available skills, defect resolution, and the quality requirements that still need to be met.

The project team should use the chart as a planning and discussion tool rather than a performance judgment of individual team members. Its primary purpose is to make progress visible, support realistic decisions, and help the team respond to changing conditions.

Conclusion

PM FPX 4080 Assessment 5 demonstrates how sprint planning and burndown tracking can support the development of a mobile application for CapraTek’s Alfred smart thermostat. By defining a clear sprint goal, prioritizing backlog items, assigning Scrum responsibilities, and establishing a consistent Definition of Done, the team can organize its work around customer needs and product quality.

The sprint focuses on secure iOS access, an interactive thermostat dashboard, customizable usage trends, and energy-efficiency notifications. These features are intended to improve usability and customer engagement while supporting the broader objective of increasing retention by 20%.

The scenario also highlights the importance of adapting sprint plans when illness, mandatory training, or other unexpected events reduce team capacity. Accurate progress tracking, early communication, and realistic prioritization help the team respond to these disruptions without sacrificing quality.

Ultimately, successful Agile delivery depends not only on completing tasks but also on producing a tested, reliable, and valuable product increment that meets customer and business requirements.

Frequently Asked Questions

What is the main goal of PM FPX 4080 Assessment 5?

The main goal is to develop a sprint plan for CapraTek’s Alfred thermostat project. The plan defines sprint objectives, prioritizes development tasks, assigns Scrum roles, establishes completion criteria, and explains how a burndown chart can help track progress.

What is a sprint in Agile project management?

A sprint is a fixed-length period during which a Scrum team works toward a specific goal and produces a usable product increment. Sprint planning identifies the goal and selected work, while daily coordination and ongoing testing help the team make progress.

What is a sprint backlog?

A sprint backlog is the set of work selected for the sprint, together with the plan for delivering it. In the Alfred project, the backlog includes iOS security, dashboard development, customizable usage trends, and energy-efficiency notifications.

What is the purpose of a sprint burndown chart?

A sprint burndown chart tracks the amount of work remaining over time. It helps the team compare actual progress with the expected pace, identify potential delays, and discuss adjustments to the work plan.

What is the Definition of Done in Scrum?

The Definition of Done is a shared set of quality criteria that a product increment must satisfy to be considered complete. Depending on the project, these criteria may include code review, successful testing, defect resolution, documentation, and integration.

What are the Scrum Master and Product Owner responsible for?

The Scrum Master helps the team use Scrum effectively, facilitates collaboration, and supports the removal of obstacles. The Product Owner prioritizes the product backlog, clarifies requirements, and focuses the team’s efforts on maximizing product value.

How should a Scrum team respond when a member becomes ill?

The team should reassess its available capacity, identify dependencies, redistribute work where appropriate, and update its remaining-work estimates. The team should maintain its quality standards and communicate potential impacts on sprint delivery.

Can the Alfred team achieve a 20% increase in customer retention in one sprint?

A single sprint can deliver features intended to improve customer engagement, but it cannot reliably establish a sustained 20% increase in retention. The team should monitor feature adoption, customer feedback, and retention data over an appropriate period to evaluate whether the project is achieving its business objective.

References

Agile Alliance. (2021, March 3). Definition of done. https://www.agilealliance.org/glossary/definition-of-done/

Capella University. (n.d.). Sprint planning meeting. Capella Media. https://media.capella.edu/CourseMedia/pmfpx4080element236975/transcript.asp#scenario1

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