Developing and Delivering Products Professionally

PSM-I · 24 questions

• A firmware Developer finishes the code for a new obstacle-avoidance routine, but the automated sensor-calibration tests that the Definition of Done requires have not been run against a physical unit by the end of the Sprint, so what should happen to that Product Backlog item?
• With two days left in the Sprint, a program manager asks the Scrum Team to temporarily drop the "verified against the safety-certification checklist" line from the Definition of Done so this Sprint's firmware update can be marked complete before a retail deadline, so what is the appropriate response?
• Two feature teams building the same home-robot product — one for the companion app, one for the onboard firmware — each keep their own Definition of Done, and their separately "Done" work frequently fails to function correctly once combined, so what should the teams do?
• For several Sprints, the cloud-connectivity team has skipped cleaning up quick, hard-coded fixes made under launch pressure, and each new Sprint now takes noticeably longer to add features to that same code, so what is the most direct explanation?
• The firmware Developers on a home-robot product each work on their own long-lived branch and only merge everything together on the final day of the Sprint, which regularly produces last-minute merge conflicts and broken builds, so which change would most directly address the root cause?
• The companion-app Developers rely entirely on manual testing performed in the final two days of every Sprint, and this manual pass has become the team's biggest bottleneck to finishing items by Sprint end, so what practice would most directly relieve this bottleneck?
• Over several releases, the cloud-services team has kept adding new Product Backlog items to its data-sync module without ever restructuring the existing code, and each new item now takes visibly longer to design cleanly, so which practice addresses this directly?
• A firmware Developer has been stuck alone for three days on a difficult motor-control bug, working in isolation rather than asking teammates for help, and the item is now at risk of missing the Sprint Goal, so what should the Scrum Master most encourage?
• Before writing any code, a robotics company's leadership insists the entire hardware-and-software architecture for the whole product line be fully specified and locked down up front, arguing this avoids rework later, so how does this align with Scrum's approach to architecture and design?
• A newly hired firmware Developer asks why the team bothers maintaining a written Definition of Done instead of just letting each Developer decide individually when their own work feels finished, so what is the best explanation?
• At Sprint Review, the companion-app Developers discover that a new pairing-flow screen has not passed the accessibility checks required by the Definition of Done, even though it is visually complete and demoed without issue, so what should happen to this item?
• With a retail launch date only one Sprint away, the Product Owner suggests the Scrum Team declare this Sprint's device-pairing feature Done even though it still fails the pairing-reliability tests specified in the Definition of Done, reasoning that the date matters more this one time, so how should the Scrum Master respond?
• A newly formed cloud-services team joins a home-robot product that already has an app team and a firmware team, and the new team adopts a much lighter Definition of Done than the other two, skipping several checks the existing teams both require, so what problem does this most directly create?
• To hit several recent Sprint deadlines, the firmware team repeatedly skipped writing automated regression tests for a navigation module, and the following Sprint was largely consumed fixing regressions that those tests would have caught, so what does this best illustrate?
• As a robotics company's retail launch approaches, the app, firmware, and cloud teams historically schedule a dedicated multi-week "integration Sprint" right before release because their code has rarely been combined and tested together before then, so what underlying practice gap does this reveal?
• The companion-app team covers its user interface exclusively with manual testing, and several UI regressions have reached customers in recent releases because manual testers could not realistically re-check every screen every Sprint, so which change would most reduce this recurring problem?
• The motor-control firmware module has grown increasingly tangled because Developers have repeatedly added quick fixes directly into existing functions rather than restructuring them, and even small new Product Backlog items now require touching many unrelated parts of the file, so which practice would most directly improve this over time?
• One Developer on the firmware team is the only person who understands the low-level driver code, rarely documents anything, and has not paired with or explained the code to any teammate, creating a serious risk if that person is ever unavailable, so what does the Scrum Team's expectation of working together most directly call for here?
• At the very start of a new robotics product line, leadership wants every architectural decision for the next two years of hardware and software locked in during a single upfront planning phase before any Sprint begins, and a Scrum Master is asked whether this fits how Scrum expects design to work, so what is the accurate answer?
• During Sprint Review preparation, the Developers realize that a firmware update for battery management has not passed the required stress-test cycle specified in the Definition of Done, so how should this item be handled at the Sprint Review itself?
• A Developer proposes that this particular Sprint's Definition of Done skip the usual stress-test requirement for a new charging-dock feature, reasoning that "it's not really needed this time" since the feature seems simple, so what is the concern with this proposal?
• A new hardware-integration team is being added to a robotics product that already has an established, shared Definition of Done used by the app and firmware teams, and the new team wants to start with its own lighter version "until it settles in," so what is the appropriate approach?
• After several Sprints of quick hacks made to hit a retail launch date, the cloud-services team's release velocity has slowed noticeably, and the Scrum Master notices this pattern during Sprint Retrospectives, so what would be the most appropriate way for the Scrum Master to respond?
• Given that hardware constraints like PCB manufacturing lead times and firmware flash cycles make it hard to iterate as quickly as pure software, what should a Scrum Team at a home-robot company do to still reliably produce a usable, Done Increment every Sprint?