6 Agile and Risk Management
Risk Registers, Hardware Sprints, Definition of Done, Kanban Flow, Design Sprints, Evidence Gates, and IoT Release Controls
6.1 Start With the Risk That Can Break the Sprint
Imagine a sprint that closes every task but still cannot answer whether the radio link survives a freezer door, whether the battery budget is real, or whether the alert reaches the duty phone. Agile risk work starts with the assumption that can hurt the release most, then shapes the sprint goal around evidence instead of activity.
6.2 In 60 Seconds
Agile is useful for IoT only when it creates evidence faster than the project creates risk. A sprint that produces only status updates is not agile. A sprint that proves battery draw, radio range, cloud ingestion, enclosure fit, supply alternatives, security assumptions, and user workflow risk is useful.
Risk management is the discipline that decides what must be tested first. Agile cadence is the discipline that makes that testing repeatable. For hardware-heavy IoT work, the strongest process blends iterative discovery with explicit gates: prototype evidence, lab evidence, sourcing evidence, compliance evidence, security evidence, and a Definition of Done that prevents quality from drifting.
Phoebe’s Why
A “3000 mAh” rating is charge, not energy – you only get watt-hours once you multiply by voltage, and that voltage itself sags under load through the pack’s own internal resistance, an Ohm’s-law effect that gets worse near end of discharge. But the more overlooked failure sits on the current side. A weak RF link rarely dies outright; it retries, and every retry is a full extra transmit burst paid from the same energy budget. A service-life claim is really an average-current budget spread over sleep and transmit time, so RF path loss and battery life are the same arithmetic problem viewed from two ends.
The Derivation
Energy from charge and voltage:
\[E = Q \times V\]
Ohm’s-law voltage sag under transmit current \(I\) through internal resistance \(R_{int}\):
\[V_{term} = V_{oc} - I\,R_{int}\]
Average current from a sleep/transmit duty cycle \(d = T_{TX}/T_{interval}\):
\[I_{avg} = I_{sleep}(1-d) + I_{TX}\,d\]
Service life from the capacity and that average current:
\[t_{life} = \frac{Q}{I_{avg}}\]
Worked Numbers: The 18-Month ESP32-S3 Claim
This chapter names an ESP32-S3 node and an example 18-month service interval but gives no cell values, so the worked numbers use catalog-typical 2xAA lithium-primary figures: \(Q=3000\) mAh, \(V=3.0\) V (2 series cells), \(R_{int}=150\ \text{m}\Omega\)/cell.
- Energy: \(E = 3.000\text{Ah}\times3.0\text{V} = 9.00\) Wh
- 18-month current budget: \(13140\) h \(\times I_{avg}=Q\) gives \(I_{avg,budget}=3000/13140=228\ \mu\text{A}\)
- Baseline design (180 mA, 300 ms TX burst every 300 s, 20 \(\mu\)A sleep): \(d=0.001\), \(I_{avg}=200\ \mu\text{A}\), so \(t_{life}=3000/0.200=15{,}000\) h \(\approx20.6\) months – a 14% margin over the target
- One RF-driven retry (weak path-loss margin doubles the burst to 600 ms): \(d=0.002\), \(I_{avg}=380\ \mu\text{A}\), so \(t_{life}=3000/0.380=7900\) h \(\approx10.8\) months – a single retry per uplink erases the 18-month claim
- Voltage sag at 180 mA: fresh pack (\(R_{int}=300\ \text{m}\Omega\)) sags \(0.180\times0.300=54.0\) mV; end-of-life pack (catalog-typical 3x resistance rise, \(900\ \text{m}\Omega\)) sags \(0.180\times0.900=162\) mV
The risk-register lesson: “battery life is risky” should become “the average-current budget has 14% margin against a poor-RF retry case that costs 1.9x the baseline current” – a number the team can actually gate a sprint on.
6.3 Learning Objectives
After this chapter, you should be able to:
- Build an IoT risk register that records cause, effect, owner, trigger, mitigation, evidence, and decision date.
- Use qualitative probability and impact ratings without pretending weak estimates are precise forecasts.
- Adapt Scrum concepts such as Product Goal, Sprint Goal, Increment, and Definition of Done to hardware and firmware work.
- Use Kanban flow and work-in-progress limits for lab queues, supplier qualification, certification, and integration work.
- Decide when a design sprint is appropriate for user or product uncertainty and when engineering validation is required.
- Create a release packet that links agile work items to risk retirement evidence.
6.4 Agile Retires Risk
Agile practice helps IoT teams when each cycle closes a named uncertainty. A sprint should not merely move tickets. It should prove whether a sensor, radio, enclosure, firmware path, cloud path, security control, or field workflow can meet the next project decision.
The risk register gives the work its order. The backlog turns high-risk assumptions into testable increments. The Definition of Done prevents the team from accepting work that has code but no measurement, no trace, no review, or no recovery plan.
For a classroom environmental monitor, the first useful agile question is not “how many features did we finish?” but “which uncertainty became smaller?” A one-week cycle might prove that an ESP32-S3 can read a BME280, survive a missing-sensor boot, publish through MQTT QoS 1 over TLS, and recover after Wi-Fi drops. That evidence reduces hardware, firmware, network, and cloud risk at once. A different cycle might discover that the enclosure blocks airflow or that the dashboard freshness rule hides stale readings. In that case the sprint still helped because it exposed a boundary the plan had missed.
The practical habit is to write each backlog item as a learning claim. “Build battery dashboard” becomes “show whether the dashboard can distinguish fresh samples, stale samples, missing samples, and low-battery samples before the pilot review.” That wording keeps the team focused on the decision the evidence must support.
- Product risk: The user workflow, installation sequence, dashboard interpretation, support model, or business promise may be wrong.
- Engineering risk: Battery life, RF range, memory use, thermal behavior, enclosure fit, firmware update, or gateway reliability may fail under real conditions.
- Release risk: Certification, sourcing, security operations, data retention, incident response, or field support may not be ready when the product ships.
6.5 Retire One Assumption per Sprint
Write the Sprint Goal as a decision the team needs to make. For example: “prove that an ESP32-S3 node can publish temperature readings over MQTT QoS 1 through TLS to AWS IoT Core while surviving a Wi-Fi outage and watchdog restart.” That goal is stronger than “finish telemetry story” because it names the device, transport, failure mode, service boundary, and acceptance evidence.
Attach a hardware-aware Definition of Done to each risky increment. A battery sprint might require a Joulescope or Nordic Power Profiler trace, sleep-current measurement, sensor warm-up profile, and projected duty cycle. A radio sprint might require RSSI/SNR samples, packet-loss counts, antenna placement notes, Wireshark or broker logs, and a repeatable test route. A security sprint might require device identity, certificate rotation, OTA rollback, audit events, and a recovery procedure.
Keep the increment small enough that the evidence can be reviewed in the sprint review. A LoRaWAN range risk might use one node, one gateway, a fixed spreading-factor plan, a mapped walk route, and a table of RSSI, SNR, frame count, and missed uplinks. A cloud-ingestion risk might use one topic, one schema version, one rejected payload, and one dashboard query that proves freshness. The team should leave the review with a decision: retire the risk, reduce it with a follow-up test, accept it with an owner, transfer it to a supplier, or block the backlog item until stronger evidence exists.
- Choose the risk first. Start with the assumption that can most damage cost, schedule, safety, security, or field adoption.
- Limit the increment. Use one node, one gateway or broker, one service path, and one measurable failure mode before adding scope.
- Close with a decision. Mark the risk retired, reduced, accepted, transferred, or still blocked, and update the backlog immediately.
6.6 IoT Agile Fails at Boundaries
The hidden cost in IoT planning is boundary mismatch. Firmware may pass a unit test but miss an MQTT retransmission edge case. A BLE GATT workflow may work in a demo but fail when connection intervals, phone background limits, or pairing recovery are included. A LoRaWAN prototype may pass uplink tests but run into ADR behavior, downlink scarcity, regional duty-cycle limits, or gateway backhaul outages.
Agile controls must therefore expose state across layers. Firmware state includes watchdog resets, brownout handling, heap use, flash wear, and OTA slot health. Network state includes join success, retry counts, queue depth, RSSI/SNR, TLS session failures, and broker acknowledgements. Service state includes schema version, alert latency, retention rule, dashboard freshness, permission model, and incident handoff.
The reason boundary evidence matters is that IoT defects cascade. A marginal sensor connection can create firmware retries, which drain the battery, which causes missed network joins, which makes a dashboard look stale, which triggers a support incident. If the sprint evidence records only the final dashboard symptom, the team fixes the wrong layer. If it records source samples, firmware counters, broker acknowledgements, cloud validation failures, and the operations alert, the team can decide which layer owns the risk and which backlog item should change next.
This is why mature teams connect agile boards to engineering telemetry. A ticket closes only when the related trace, log, capture, test report, or operator runbook is attached, and when the owner has named the next risk state. Without that evidence, “done” is just a workflow label.
- Embedded boundary: FreeRTOS or Zephyr tasks, interrupt timing, I2C/SPI/UART errors, flash configuration, watchdog policy, and update rollback.
- Network boundary: MQTT QoS semantics, CoAP confirmable messages, BLE reconnect behavior, Thread route changes, LoRaWAN airtime, and Wi-Fi roaming.
- Operations boundary: Grafana dashboards, Prometheus alerts, AWS IoT Core or Azure IoT Hub policies, certificate expiry, log retention, and field-support runbooks.
6.7 Agile and Risk Belong Together
IoT projects combine software uncertainty with physical constraints. Firmware can change daily. PCB fabrication, enclosure tooling, sensor qualification, radio testing, and certification can take longer. That mismatch is where risk hides.
Short cycles are not an excuse to skip evidence. For IoT, the Definition of Done must include the proof the product needs: measurements, traces, logs, test reports, schematic reviews, threat checks, and owner sign-off when a risk is accepted.
6.8 Convert Risk to Sprint Evidence
The useful unit of agile risk work is not a meeting, a ticket, or a demo. It is a risk that moves because the team collected stronger evidence.
- Write the risk as a cause-and-effect claim. “Battery life is risky” is vague. “The ESP32-S3 node may miss the 18-month service interval because sensor warm-up and Wi-Fi reconnect current are unmeasured” gives the team something to test.
- Choose the workflow that fits the constraint. Use a sprint goal for firmware or cloud increments, Kanban for lab queues and supplier qualification, a design sprint for user workflow uncertainty, and a formal gate when compliance, safety, or release approval depends on evidence.
- Name the evidence before starting the work. A power risk might need a Joulescope or Nordic Power Profiler trace, a radio risk might need RSSI/SNR and packet-loss logs, and a cloud risk might need MQTT broker acknowledgements, schema validation failures, and dashboard freshness checks.
- Close the loop with a decision. Retire, reduce, accept, transfer, or reopen the risk, then update the backlog so the next sprint does not repeat the same uncertainty.
6.9 Incremental Examples
Beginner Example: A classroom sensor prototype uses an ESP32 board and a BME280 over I2C. The first risk is not market fit; it is whether the board, sensor, wiring, and firmware path can produce stable readings. A useful sprint captures the board profile, I2C address scan, serial log, and one unplugged-sensor failure case before moving to enclosure or dashboard work.
Intermediate Example: A gateway prototype publishes telemetry with MQTT over TLS to AWS IoT Core, Azure IoT Hub, Mosquitto, or EMQX. The risk is no longer only “can it publish once.” The sprint should test reconnect behavior, QoS choice, duplicate handling, certificate expiry path, payload schema rejection, and dashboard freshness after a Wi-Fi outage.
Advanced Example: A field pilot combines Zephyr or FreeRTOS firmware, signed OTA updates, a LoRaWAN or cellular backhaul, battery service targets, and support operations. The team may need sprint increments for firmware behavior, Kanban lanes for lab and supplier queues, and release gates for security, compliance, and operations readiness. The agile method is useful only if each layer leaves reviewable evidence.
6.10 Risk Register
A risk register is useful only when it drives action. Avoid vague entries such as “hardware might be late.” Write the cause, effect, trigger, owner, mitigation, and evidence needed to close the risk.
risk:
id: sensor-source-01
cause: only_one_qualified_pressure_sensor
effect: pilot_build_blocked_if_sensor_allocation_changes
trigger: supplier_lead_time_exceeds_build_window
owner: hardware_lead
mitigation: qualify_second_source_and_pinout_adapter
evidence: evaluation_report, firmware_driver_test, revised_bom
decision: mitigate_this_sprint6.11 Probability-Impact Ranges
Probability-impact matrices are useful for triage, but weak numbers can become false confidence. Use ratings, ranges, and supporting observations unless the team has data strong enough for a numerical model.
Expected-loss worksheets can compare mitigation choices, but the inputs are often rough. Use them to reveal assumptions, not to pretend a single number proves the future. Record the evidence behind the rating.
6.12 Concept Check: Risk Entry Strength
6.13 Scrum Adaptation for IoT
Scrum is a lightweight framework for adaptive work. The official Scrum Guide centers empiricism, transparency, inspection, adaptation, Product Goal, Sprint Goal, Increment, and Definition of Done. For IoT, those ideas help only when the increment includes cross-layer evidence.
Name the product outcome: reliable sensor pilot, certified gateway, validated installation workflow, or secure firmware update path.
Choose a goal that retires a real risk, not a list of disconnected tasks.
A usable increment may be a measured prototype, validated firmware path, tested cloud pipeline, or reviewed design package.
Done should include evidence such as test logs, power traces, radio captures, security checks, and sprint review decisions.
6.13.1 Hardware-Aware Definition of Done
For a software-only feature, Done might mean tested, reviewed, integrated, and documented. For an IoT increment, Done often needs additional proof.
Do not stretch sprints until they become phase gates. Keep the learning cadence short, but use flow lanes and explicit dependencies for work that must wait on fabrication, shipping, lab slots, or certification.
6.14 Kanban Flow for Hardware Constraints
Kanban is useful when work waits in queues: lab test slots, procurement, PCB review, firmware integration, certification evidence, enclosure changes, or customer installation feedback. The key is to visualize the workflow, limit work in progress, and actively manage blocked items.
6.15 Design Sprints for Product Uncertainty
Design sprints can be useful when the team needs fast evidence about users, workflow, installation, service experience, onboarding, dashboard interpretation, or buying assumptions. They are not a substitute for radio testing, power profiling, safety analysis, or manufacturing review.
Validate problem framing, interface, field workflow, dashboard comprehension, service journey, or install sequence.
Do not use a design sprint to claim battery life, RF compliance, certification readiness, or manufacturability.
User feedback should become backlog items, risk entries, lab tests, or named follow-up decisions.
Capture hypothesis, prototype, participants, observations, decision, and follow-up test needs.
6.16 Iterative Work With Real Gates
The common mistake is presenting Agile and Waterfall as opposites. IoT projects often need both iterative learning and explicit gates. The issue is not which label sounds better. The issue is whether the process reveals risk early and preserves evidence.
6.17 Label the Agile Risk Evidence
6.18 Code Challenge: Risk-Gated Sprint Record
6.19 Concept Check: Process Fit
6.20 Common Pitfalls
6.20.1 Calling Status Meetings Agile
Daily status does not reduce risk by itself. The cadence matters only if it changes what the team learns, builds, tests, or stops doing.
6.20.2 Letting Hardware Wait Outside the Board
PCB fabrication, supplier quotes, lab slots, fixtures, and certification feedback should be visible. Hidden queues create false confidence in sprint progress.
6.20.3 Definition of Done Is Not a Box
Done must match the product risk. A card is not done because it moved columns. It is done when the required evidence exists and the responsible owner accepts the result.
6.20.4 Design Sprints for Proof
A design sprint can validate a workflow or product assumption. It cannot prove radio compliance, battery life, durability, safety, or production yield.
6.20.5 Risk Scores Need Uncertainty
Risk scores are decision aids. If the evidence is weak, say so. Record confidence, assumptions, and the next test rather than presenting an exact-looking number.
6.21 Release Checklist
Cause, effect, trigger, owner, mitigation, evidence, confidence, and decision date are current.
Sprint increments include measurements, tests, logs, review artifacts, and owner acceptance.
Lab, supplier, certification, integration, and review queues have WIP limits and blocked-item owners.
Hardware, firmware, cloud, security, compliance, manufacturing, and support risks have closure records.
Any accepted risk has a named owner, reason, trigger, contingency, and next review date.
Evidence changes the backlog, design, risk register, schedule, or release decision.
Choose one open risk from a current IoT prototype or pilot and complete a one-row gate record before moving it to done.
| Gate field | Record |
|---|---|
| Risk and owner | Name the risk, the accountable owner, and the product or release decision it affects. |
| Evidence required | List the measurement, test log, review artifact, supplier confirmation, or user workflow result needed to reduce the risk. |
| Decision rule | Write the pass, mitigate, hold, or stop condition in one sentence. |
| Next trigger | Name the calendar date, lab result, field event, or backlog change that reopens the risk. |
Accept the gate only when the evidence, decision rule, owner, and next trigger are all visible in the backlog or release packet.
6.22 Micro-Exercise: Pick the Right Control
For each signal, choose the management control that should act first:
- A mobile installer cannot complete onboarding without help: use a design sprint or field-workflow prototype before changing the firmware.
- Three cards are waiting for the same battery-profile lab bench: use a Kanban lane with WIP limits and a visible blocked state.
- A release claims signed OTA rollback works: use a gate with a failed-update test, boot-slot evidence, and rollback log before release approval.
6.23 Self-Assessment
6.24 Summary
Agile and risk management reinforce each other when the team treats every cycle as a chance to produce evidence. For IoT, that evidence must cross software, hardware, data, security, supply, regulatory, and field-use boundaries.
The strongest approach is not a pure methodology label. It is a disciplined operating model: visible risk register, evidence-based Definition of Done, WIP-limited flow for constrained work, design sprints for the right uncertainties, and release gates that prevent quality drift.
6.25 Concept Relationships:
- Design Thinking Project Planning introduces project structure, resources, and milestone thinking.
- Design Thinking Validation explains how evidence should change product direction.
- Design Thinking Implement and Iterate builds on sprint evidence and continuous learning.
- Testing and Validation expands the test evidence needed for hardware, firmware, and system release.
- Specification Sheet Fundamentals helps turn component uncertainty into specific risk entries and tests.
6.26 What’s Next
| If you need to… | Read next |
|---|---|
| Plan the broader design-thinking path | Design Thinking Project Planning |
| Validate product assumptions with users | Design Thinking Validation |
| Turn sprint learning into implementation | Design Thinking Implement and Iterate |
| Build stronger test evidence | Testing and Validation |
| Review hardware component risk | Specification Sheet Fundamentals |
6.27 Official References
- Principles behind the Agile Manifesto - early delivery, changing requirements, frequent delivery, technical excellence, simplicity, and reflection.
- The 2020 Scrum Guide - Scrum definition, empiricism, Scrum Team, events, artifacts, Sprint, and Definition of Done.
- The Kanban Guide - workflow visualization, active workflow management, WIP, and flow improvement.
- Google Design Sprint Kit - design sprint methodology for fast product and user learning.
- ISO 31000:2018 Risk management - principles, framework, process, and current status of the risk management standard.
6.28 Key Takeaway
Agile planning in IoT should reduce uncertainty without hiding hardware risk. Iterate quickly, but keep explicit risk registers for supply, power, certification, security, field access, and integration dependencies.