Scrum Methodology in a Kotlin Project (Iterative Development of Four Features)

Overview of Scrum in Iterative Development

Scrum is a popular Agile framework that structures development into fixed-length iterations called Sprints (typically 1–4 weeks long). It defines specific roles (Product Owner, Scrum Master, Development Team) and ceremonies (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) to manage and inspect progress. In a Kotlin project where a customer has requested four features, Scrum provides a clear, time-boxed approach to deliver these features incrementally while handling changes and obstacles in a controlled way.

In Scrum, all work to be done lives in the Product Backlog – a prioritized list of user stories/features maintained by the Product Owner. At each Sprint Planning meeting, the team pulls a set of the highest priority items (e.g., these four features, likely one or two per sprint depending on size) into the Sprint and commits to deliver a Sprint Goal by the end. The iterative development process in Scrum means each feature will go through a cycle of planning, development, testing, and review within a sprint, culminating in a potentially shippable product increment. The team inspects progress in the Sprint Review and adapts their process in the Sprint Retrospective, then the cycle repeats with the next sprint.

Below, we follow each of the four features through the Scrum process, detailing how Scrum handles:

1. A feature with incorrect scope that becomes blocked.
2. A feature with changing requirements mid-sprint.
3. A feature delayed by external dependency issues.
4. A feature that goes smoothly from start to release.

flowchart TD
    Backlog["Product Backlog"] --> |Select for Sprint| SprintPlanning
    SprintPlanning --> SprintExecution[Development & Testing]
    SprintExecution --> SprintReview["Sprint Review"]
    SprintReview --> SprintRetro["Sprint Retrospective"]
    SprintRetro --> |Next Iteration| NextSprintPlanning[Next Sprint Planning]
    SprintExecution --> |"Scope unclear (Feature 1)"| BlockedScope{Remove from Sprint & Re-Backlog}
    SprintExecution --> |"Mid-sprint change (Feature 2)"| ChangeReq{Re-negotiate Scope}
    ChangeReq --> |If minor change| AdjustedInSprint[Adjust within Sprint]
    ChangeReq --> |If major change| NewItem["New Story in Backlog for change"]
    SprintExecution --> |"Ext. dependency (Feature 3)"| BlockedDep{Mark Blocked, possibly swap out}
    SprintExecution --> |"Feature done (Feature 4)"| Completed[Work Completed]
    Completed --> SprintReview
    BlockedScope --> Backlog
    NewItem --> Backlog

In this diagram, the Scrum process is visualized from backlog to sprint execution and review. Various scenarios are shown: a feature with unclear scope (Feature 1) can be removed from the sprint and put back into the backlog (to be refined later), a mid-sprint change (Feature 2) leads to re-negotiating scope (either adjusting within the sprint or planning it for later as a new backlog item), an external dependency issue (Feature 3) is marked as blocked (possibly prompting the team to swap it out or wait), and completed work (Feature 4) goes to Sprint Review. After the Sprint Review and Retrospective, the next sprint begins with planning (continuing the cycle).

Feature 1: Incorrect Scope (Blocked in Scrum)

Situation: Feature 1 was pulled into a Sprint (Sprint 1) during Sprint Planning. Partway into Sprint 1, the development team realizes that the scope or requirements of Feature 1 are unclear or incorrect. Perhaps a user story was not well-defined, or new information shows the initial assumptions were wrong. The team cannot proceed without significant clarification – Feature 1 is effectively blocked within the sprint.

Scrum’s Approach:

• Impediment raised: Scrum teams surface issues immediately in the Daily Scrum (stand-up). When the team hits the scope confusion, they flag Feature 1 as an impediment. The Scrum Master’s role is to help remove this impediment. That might involve coordinating a discussion with the Product Owner or customer to get more details. In Scrum, any blocker to progress is taken very seriously and addressed as soon as possible.
• No quick fix → remove from sprint: If the clarification can’t be obtained quickly (say within a day or two), the team and Product Owner discuss removing Feature 1 from the sprint. According to Scrum principles, work that is not ready or is blocked should not continue to occupy the team’s sprint capacity. The Product Owner can decide to pull the story out of the Sprint Backlog and return it to the Product Backlog for rework. This keeps the Sprint focused on achievable goals. It’s better to deliver a smaller increment successfully than to struggle with a stuck item and risk the whole sprint goal.
• Sprint Goal consideration: Scrum is commitment-based – the team commits to a Sprint Goal. If Feature 1 was essential to the Sprint Goal, its removal might endanger that goal. The Scrum Guide states “during the Sprint, no changes are made that would endanger the Sprint Goal.” (Sprint Goal a difficult balance | Scrum.org) In this case, the Product Owner might consider cancelling the sprint entirely if the goal can’t be met without Feature 1. However, sprint cancellation is rare and usually only done if the Sprint Goal becomes obsolete or impossible. More commonly, if Feature 1 is not central to the Sprint Goal, the team can continue the sprint with other work and still deliver value (albeit less than originally planned). The Sprint Goal might be adjusted if needed, with agreement from the team.
• Backlog refinement: Once removed from the sprint, Feature 1 goes back to the backlog. The Product Owner (with input from the team) will prioritize figuring out the scope problem. They might rewrite the user story, gather additional requirements from the customer, or split the feature into smaller stories. This typically happens in a Backlog Refinement session or ad-hoc discussion during the sprint. The goal is to ensure Feature 1 meets a “Definition of Ready” (clear, agreed-upon, and testable) before bringing it into another sprint. Some Scrum teams use the concept of Definition of Ready to prevent ill-defined work from entering a sprint in the first place.
• Utilize freed capacity: With Feature 1 removed, the team now has some free capacity in the sprint. Scrum doesn’t encourage adding completely new scope mid-sprint, but the team can pull in another existing backlog item (preferably of high priority) if the Product Owner and team agree it makes sense and can be completed within the remaining time. Alternatively, the team focuses on completing the other committed sprint items with higher quality (e.g., doing extra testing or refactoring). The Scrum Master might facilitate a quick re-planning within the team to decide how to best use the time freed by Feature 1’s removal.
• Next sprint: In a later sprint, once Feature 1’s scope is fully clarified, it can be planned again. By now the previous blocking issue has been resolved through analysis and clarification. The team then implements Feature 1 in that future sprint and completes it successfully.

Lifecycle in Scrum: During Sprint 1, Feature 1 was started but then halted and removed. It was returned to the backlog for further refinement. By Sprint 2, assume the team has clarified Feature 1 with the customer; they include it in Sprint 2’s Sprint Planning with proper understanding. In Sprint 2, they finish development and testing of Feature 1. It goes through Sprint 2’s review (where the customer finally sees it done correctly) and is accepted. At the Sprint 2 end, Feature 1 is part of the potentially shippable increment. The team might release it then, or combine it with other features in a release, depending on the project’s release strategy (Scrum itself doesn’t require every sprint to end with a release to production, but it encourages having a releasable increment). Throughout this process, Scrum’s emphasis on clear backlog items, the Product Owner’s active backlog management, and the Scrum Master’s focus on removing impediments are key. The team also learns to improve backlog refinement to avoid poorly scoped items in the future – a topic likely discussed in the Sprint Retrospective.

Feature 2: Requirements Change Mid-Sprint

Situation: Feature 2 is being worked on in Sprint 1 as well. Midway through the sprint, the customer (via the Product Owner) comes with new requirements or a change of direction for Feature 2. For example, after seeing an early demo or due to external market changes, they decide Feature 2 should behave differently or include additional functionality. This is a classic scope change in the middle of a sprint.

Scrum’s Approach:

• Resist mid-sprint change (preserve focus): Scrum philosophy is to lock the Sprint Backlog during the sprint execution to preserve focus and predictability. The Scrum Guide allows clarification of scope, but says mid-sprint changes that endanger the Sprint Goal should be avoided (Sprint Goal a difficult balance | Scrum.org). The Product Owner and team’s first question should be: “Can this change wait until the next Sprint?” Often, the answer is yes – Scrum’s short sprints (e.g., 2 weeks) mean the customer doesn’t wait long to introduce a change at the next planning. Best practice is to add the new requirement as a new story or an updated story in the Product Backlog, to be prioritized in the next sprint, rather than disrupting the current sprint.
• If the change is critical (can’t wait): Scrum does provide a mechanism for truly urgent mid-sprint changes. The Product Owner has the authority to cancel the sprint if the change in direction is so important that continuing the sprint as is would be wasteful (for example, if a competitor’s move renders the Sprint Goal invalid, or the product needs a sudden pivot). After canceling, the work done is reviewed and any useful parts are kept, then a new sprint is planned that includes the change. However, sprint cancellation is drastic and very rare. More commonly, the team might accept a swap: remove some scope (perhaps the original Feature 2 story) and replace it with the new requirements, but only if the team agrees they can still meet an adjusted Sprint Goal.
• Negotiation and re-planning within the sprint: Let’s say the change is moderate and Feature 2 is still doable with some rework. The Product Owner and team will negotiate how to adjust. They might break Feature 2 into two pieces: what’s already built (old behavior) and what’s new. They could then decide to finish part of it now and handle the new parts next sprint. Or, if possible, implement the change now but perhaps drop another lower-priority item from this sprint to free up time. This negotiation is done collaboratively – the Scrum Team has authority to manage the Sprint Backlog as needed, as long as any decision honors the Sprint Goal. The Product Owner is there to guide priority, and developers judge what’s feasible technically.
• Developer adaptation: Assuming the team decides to incorporate the change now, developers refocus their work. They might have to throw away or refactor some code written for the old requirements. Scrum doesn’t forbid changes; it just cautions against those that undermine the goal. If the team has good engineering practices (like version control, automated tests, continuous integration), adapting mid-sprint is technically manageable — just not ideal from a planning perspective. The presence of automated tests (perhaps written earlier or as part of the Definition of Done) can help ensure that in making changes, nothing else breaks. The team may also log the extra work incurred due to the change, to discuss in retrospective.
• Transparency: The team updates the Sprint Backlog to reflect the new plan for Feature 2. They communicate this in the Daily Scrum so everyone knows of the pivot. The Sprint Burndown chart (if they use one) might show a strange pattern (maybe work remaining goes up if new tasks are added). The Scrum Master will ensure this change is visible and understood by stakeholders. It might be mentioned in the Sprint Review that “Feature 2’s scope was changed mid-sprint, here’s what we were able to achieve.”
• Sprint Goal check: A crucial step is checking the Sprint Goal. If the Sprint Goal can still be met with this change, the sprint continues. If not, the Sprint Goal might be adjusted with team consent, or in extreme cases, the sprint is canceled as noted. For example, if Feature 2 was the only item in the Sprint Goal and now it’s fundamentally different and larger, the team might officially abort the sprint and start a new one with a new goal. But if Feature 2 was one of several items and the others still deliver some coherent value, they might keep the sprint going and accept that Feature 2 might not be fully delivered.
• Completion and review: Suppose the team manages the change and finishes the updated Feature 2 by end of the sprint (or it could slip to the next sprint if it became too big – Scrum is flexible in that an item can carry over as undone). In the Sprint Review, they demonstrate whatever is completed of Feature 2. If it’s fully implemented as per new requirements, great – stakeholders review it and give feedback. If it’s partially done, the Product Owner will mark Feature 2 as not “Done” (according to the Definition of Done) and return it to the backlog to continue later. Either way, stakeholders are made aware of the change and the rationale behind mid-sprint adjustments. They might even appreciate that the team was able to respond quickly.
• Next sprint: Any remaining work for Feature 2 or further tweaks are taken up in the next sprint planning. By that time, the team has the experience of the changes and can plan accurately. Feature 2 gets finished in Sprint 2 (if it wasn’t already) and is then released. The delay, if any, is contained to the minimum because Scrum allowed only what was truly necessary to change mid-sprint.
• Retrospective insights: The team will certainly discuss this in the Sprint Retrospective. Why did the change come mid-sprint? Could it have been foreseen or communicated earlier? They might decide on actions like involving stakeholders more in Sprint Reviews to catch such changes between sprints, or improving backlog refinement to adapt to emerging requirements before a sprint begins. They’ll also acknowledge their ability to be flexible: sometimes, despite best planning, changes will occur and the team handled it following Scrum values of openness and courage.

Lifecycle in Scrum: Scrum attempts to contain change within iteration boundaries, but it’s not inflexible if a change is truly needed immediately. In our scenario, the team either defers Feature 2’s changes to the next sprint or replans Sprint 1 on the fly to accommodate them. The key is that changes mid-sprint are carefully managed to avoid derailing the sprint. Ideally, Feature 2 is completed to the new specification by Sprint 1’s end or in Sprint 2, and then released. The retrospective for Sprint 1 would likely discuss why the change came mid-sprint – could it have been handled better? Scrum teams aim to improve planning and stakeholder engagement to minimize mid-sprint scope churn, while still keeping the customer happy by being responsive when absolutely necessary.

Feature 3: External Dependency Delay in Scrum

Situation: Feature 3 depends on work from another team (say an API service or library that the other team owns). The team planned Feature 3 in a sprint (Sprint 2, for example) assuming the dependency would be delivered on time. During development of Feature 3, it becomes clear that the other team’s component is delayed or that a change on their side is causing integration issues. Our team is now blocked waiting for that dependency, jeopardizing completion of Feature 3 in the sprint.

Scrum’s Approach:

• Impediment tracking: Just like with Feature 1’s scope issue, the dependency delay is treated as an impediment. The team flags Feature 3 as blocked in the Daily Scrum and likely on their Scrum board. The Scrum Master takes action to expedite a resolution – this might mean the Scrum Master contacts the other team’s Scrum Master or project lead to get updates and advocate for our team’s needs. The Scrum Master might also escalate the issue to management if the dependency is critical and at risk.
• Focus on what’s controllable: During the sprint, the team asks: “Is there any part of Feature 3 we can complete without the dependency?” They might proceed with pieces that don’t require the external component, or prepare the integration code and write tests while waiting. If they can simulate the dependency (e.g., use a stub service in place of the real API), they do so to at least test our side of the integration. This aligns with the Scrum value of commitment – the team does everything they can to meet the Sprint Goal, improvising if necessary.
• Swap if possible: If Feature 3 was not the only item in the sprint, the team might swap it out once it’s blocked. For example, the Product Owner could bring a lower-priority item from the backlog into the sprint to replace Feature 3’s remaining work (provided the team agrees and it won’t jeopardize the sprint goal). This is analogous to how they handled Feature 1’s removal – any swap should be done only if it helps meet the Sprint Goal. If Feature 3 was a significant part of the Sprint Goal, removing it might compromise the sprint outcome; the team and Product Owner then have to decide whether to accept that the sprint will have an incomplete item or to adjust the sprint goals.
• Transparency with stakeholders: In the Sprint Review for that sprint, if Feature 3 isn’t done, the delay and reasons are explained. Scrum is transparent – stakeholders learn that “Feature 3 could not be completed because we’re waiting on X from Team B.” This sets correct expectations and often prompts discussion on how to prevent such issues. Perhaps a manager will assist in prioritizing that dependency or the stakeholder will understand the need to adjust delivery timelines.
• Re-plan next sprint: Assuming the dependency is delivered by the time the next sprint starts, the team will include the remaining work of Feature 3 in that next sprint (Sprint 3). If the dependency is still not ready, the Product Owner may decide to leave Feature 3 out of the next sprint and instead focus on other features (like Feature 4 or new backlog items) until the dependency is resolved. Scrum’s empirical approach means each sprint planning they consider the latest information – if Feature 3 is still blocked, they won’t plan it again yet.
• Integration once ready: When the external team finally provides their component (say early in Sprint 3), our team quickly integrates it and finishes Feature 3. They make sure to coordinate closely – maybe perform an early integration test outside of sprint work to validate the dependency as soon as it arrives. Once integrated, they test Feature 3 thoroughly and ensure it meets the Definition of Done.
• Scrum-of-Scrums (if applicable): In organizations with multiple Scrum teams, a Scrum-of-Scrums meeting (a regular coordination meeting of representatives from each team) can help surface such dependencies ahead of time. If this practice was in place, the dependency risk for Feature 3 might have been identified earlier or mitigated by aligning sprint plans between teams. For example, Team B’s Product Owner might coordinate to deliver the API by a certain sprint if they know Team A (our team) needs it in Sprint 2.

Lifecycle in Scrum: Feature 3 started in one sprint, got delayed, and finished in a later sprint. Scrum’s time-boxing meant that the unfinished Feature 3 simply remained unfinished at the end of Sprint 2 and rolled back to the Product Backlog (or carried over with explicit re-planning in Sprint 3). It was not counted as “Done”. In Sprint 3, with the dependency resolved, the team completed Feature 3 and demonstrated it in Sprint 3’s review, delivering it as part of that increment. The iterative approach allowed the team to still deliver other items in Sprint 2 (instead of being completely blocked), and then focus on Feature 3 when possible. The retrospective would cover how to avoid or better manage such delays: for example, including integration tests for external APIs early in the sprint to catch issues sooner, improving communication with the other team, or negotiating interface contracts ahead of time.

Feature 4: Smooth Sailing to Release with Scrum

Situation: Feature 4 is developed in a sprint (say Sprint 2 or Sprint 3) and it proceeds without any notable problems. The requirements are clear, no external dependencies, and no mid-sprint changes occur. It’s the ideal scenario of planned work executed and delivered as expected within the sprint.

Scrum’s Approach:

• Sprint Planning: The team picks up Feature 4 in the Sprint Planning session. They discuss the user story in detail, confirm understanding with the Product Owner, and estimate the effort. Feature 4 is included in the Sprint Backlog and contributes to the Sprint Goal (perhaps the Sprint Goal is to deliver Feature 4 functionality, or Feature 4 is part of a broader goal). The team feels confident in accomplishing it within the sprint.
• Daily Scrum & Development: Each day, the team collaborates and syncs on progress. Because Feature 4 is going well, updates in stand-ups are straightforward: “working on implementation, no blockers.” If any small questions arise, the Product Owner (who is readily available) clarifies them quickly, but these are minor and don’t change the scope. The developers proceed with coding Feature 4 in Kotlin, writing unit tests for new code, and ensuring they adhere to the team’s Definition of Done.
• Development Practices: Scrum doesn’t dictate how to do the work, but Scrum teams often leverage XP practices or other engineering best practices. For Feature 4, the team might use pair programming to build a complex part of the feature, or practice test-driven development to ensure a robust implementation. They frequently integrate their code (possibly using CI pipelines), so by the time they’re done coding, the feature is already merged with the main codebase and any integration issues have been ironed out.
• Testing and Integration: During the sprint, once the coding for Feature 4 is done, the item moves to “Testing” on the Scrum board. The team (developers and any QA) verify the feature thoroughly. Because Feature 4 had clear acceptance criteria, they validate those criteria are met. They perform any necessary exploratory testing around the feature, and run the full automated test suite to ensure nothing else was impacted. The code is also peer-reviewed (if not pair programmed) as part of the Definition of Done.
• Sprint Review: At the end of the sprint, Feature 4 is completed and the team demonstrates it to stakeholders in the Sprint Review meeting. The customer sees Feature 4 working as expected. Because Scrum emphasizes producing a potentially shippable increment each sprint, Feature 4 is part of the shippable product at this point. Often, teams will actually release it at the end of the review or shortly after. The stakeholders provide feedback on Feature 4 – in this smooth scenario, likely the feedback is positive, or they might suggest minor enhancements which go into the backlog. The Product Owner confirms that Feature 4 meets the Definition of Done and accepts it.
• Release: Assuming the project’s strategy is to release at the end of each sprint (which many Scrum teams do, even though it’s not mandated), Feature 4 is deployed to production or delivered to users after Sprint 2/3’s completion. If the team follows continuous deployment, the feature might even have been deployed immediately once it was done and tested, but typically, aligning with the sprint boundary is common for coordination. In any case, by the time the sprint is over, Feature 4 is in the users’ hands or ready to be shipped.
• Sprint Retrospective: The team also reflects on why Feature 4 went well in the Sprint Retrospective. They might note that having well-defined requirements and no external blockers made a big difference. They might highlight practices that helped (e.g., “Our test-first approach caught issues early, so we had almost no bugs on Feature 4”). These insights get recorded as part of continuous improvement. If every sprint went like Feature 4’s, the team would be very productive; retrospectives help understand how to make the smooth execution repeatable.

Lifecycle in Scrum: Feature 4’s journey is contained entirely within one sprint: planned, built, tested, and demonstrated. It was likely released as part of the increment from that sprint. This is Scrum working in its most straightforward form. By delivering Feature 4 in a single sprint, the team provides value quickly and validates that their process (from planning to delivery) is working effectively. If this Kotlin project uses Scrum for all feature development, ideally most features would follow the pattern of Feature 4 – Scrum’s framework is designed to facilitate that kind of steady, predictable delivery by catching issues early (in planning or daily scrums) and enforcing quality (via the Definition of Done and review processes).

Scrum Best Practices and Unique Aspects

• Time-boxing and Focus: Scrum’s fixed-length sprints create a focused environment. This helps manage Feature 2’s scenario; rather than constantly changing course, Scrum encourages waiting until the next sprint to implement changes, thereby maintaining focus in the current sprint. The concept of a Sprint Goal provides a guiding light – changes (like requirement changes or adding new work) are judged against the Sprint Goal to decide if they’re allowed. Time-boxing also meant that Feature 3’s delay did not go on indefinitely; the sprint ended, and the team re-evaluated the plan fresh in the next sprint.
• Clear Roles and Responsibilities: Scrum’s roles ensure accountability and clarity. The Product Owner advocates for the customer, manages the backlog, and sets priorities (as we saw in deciding how to handle changes for Feature 2 and Feature 1’s removal). The Scrum Master facilitates the process and removes impediments (helping with Feature 1’s scope issue and Feature 3’s dependency by coordinating and shielding the team). The Development Team self-organizes to meet the sprint commitment (finding ways to still deliver value despite setbacks, such as working on other items when Feature 1 or 3 were blocked). This separation of concerns helps the team respond to issues quickly without confusion over who decides what.
• Ceremonies (Inspect & Adapt): Scrum has built-in events for continuous improvement. The Sprint Review is where adaptation happens regarding the product (e.g., new requirements for Feature 2 emerged and can be added to the backlog for future sprints). The Sprint Retrospective is where the process is adapted (e.g., improving how the team refines backlog items to avoid another Feature 1 scenario, or how to better coordinate external dependencies after Feature 3’s issue). This structured inspect-and-adapt cycle is a hallmark of Scrum. Every sprint is an opportunity to not only deliver product increments but also to refine how the team works.
• Definition of Done: Scrum teams use a Definition of Done to ensure quality and completeness of work. This was crucial for Feature 4 to be truly shippable by sprint’s end. It also plays a role in deciding if a partially done feature (like Feature 2 when requirements changed mid-sprint, or Feature 3 when blocked) can be considered “done” or not. If it doesn’t meet the DoD, it cannot be counted as a completed increment. This maintains high quality and avoids half-baked features being released. The DoD typically includes things like “code reviewed, tests passed, integrated, documentation updated” – which ensures consistency and readiness for release.
• Predictability with Adaptability: Scrum aims for predictable delivery (through velocity, sprint commitments) but also provides adaptability between sprints. While a sprint is running, change is minimized (to protect the team’s focus), but between sprints, priorities can shift significantly. In our four features, Scrum allowed deferring changes and re-planning at the next sprint, which gives the customer flexibility at regular intervals. This is a different style of agility compared to continuous flow – it’s cadence-based agility. The trade-off is the customer waits a short time (till the next sprint) to see major changes, but the team gets a stable window to work effectively. Scrum finds a balance between responsiveness and focus.
• Team Empowerment and Self-organization: The Scrum team is self-organizing. They decide how to react to issues like these within the bounds of Scrum principles. For instance, the team collectively decided to remove Feature 1 from the sprint when it was the smart thing to do; the team (with Product Owner) negotiated how to handle Feature 2’s change; the developers figured out how to keep busy during Feature 3’s wait. Management doesn’t micromanage these decisions; the team closest to the work makes the call, guided by the Product Owner’s priorities and the Scrum Master’s coaching on Scrum values. This empowerment leads to high ownership and motivation.
• Continuous Delivery Potential: Although Scrum works in sprints, modern Scrum teams often practice continuous integration and even continuous deployment. This means features like Feature 4, or any completed work from a sprint, can be released to users frequently (even every sprint or more often if desired). Scrum’s concept of a “potentially shippable increment” ensures that at the end of each sprint, you could release the product. The actual release schedule is up to the business – some release every sprint, some bundle multiple sprints. But the capability is there. In the context of our project, that means as each of these four features was completed, it was in a state ready to deploy, allowing the company to deliver value incrementally rather than waiting for all features to be done.

Conclusion: Scrum handles the iterative development of these four features by enforcing structure (time-boxed sprints, roles, ceremonies) while still adhering to Agile principles of flexibility and customer collaboration. Feature 1’s issue was handled by stopping and re-aligning on requirements (thanks to transparency and strong backlog management). Feature 2’s change was addressed through Scrum’s disciplined approach to scope changes (protect the sprint focus, but be ready to pivot if truly necessary). Feature 3’s dependency challenge was managed by raising an impediment and adjusting plans, which Scrum Masters are trained to facilitate. Feature 4 showed how Scrum functions when preparation and execution align well – it delivers a smooth increment of value. By following Scrum, the team ensured that at the end of each sprint, they had assessed progress on all these features and adapted their plan accordingly. Over the course of the sprints, all four features were successfully released with high quality in this Kotlin project, demonstrating Scrum’s effectiveness in managing iterative development with clear checkpoints and continuous improvement.

---