Skip to content

Commit c8e9d50

Browse files
yyodsyyods
committed
[docs] record strategy and Cycle 1 Scrum delivery baseline
Signed-off-by: Viwat Vchirawongkwin <viwat.v@chula.ac.th>
1 parent b7982f7 commit c8e9d50

7 files changed

Lines changed: 1926 additions & 0 deletions

File tree

‎docs/developments/2026-q4-reliable-workflow/01_Overview_and_Scrum_Framework.md‎

Lines changed: 144 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,144 @@
1+
<!-- SPDX-License-Identifier: MIT -->
2+
<!-- Part of PyBLE (https://pyble.dev) — see /LICENSE. -->
3+
4+
# Cycle 1 — delivery guide and Scrum working agreement
5+
6+
## Document control
7+
8+
| Field | Value |
9+
|---|---|
10+
| Package | PyBLE 2026 Q4 reliable workflow, Cycle 1 (`C1`) |
11+
| Prepared | 25 September 2026; Asia/Bangkok |
12+
| Strategy | [Implementation Plan, revision 1.2](../../planning/PyBLE_Implementation_Plan_and_Strategy_v1.0.md) |
13+
| Repository baseline | `23ed764b0ef88dce9720c66fbd1c0655268860cf` |
14+
| Proposed cycle | 28 September–20 December 2026; six two-week Sprints |
15+
| Status | Proposed delivery package; no Sprint Planning, estimates, named assignments, implementation approval, or new physical results are implied |
16+
| Primary audience | Tablet-owning makers, provisionally; confirm one reachable cohort before observation |
17+
| Authoritative contracts | [Contributor rules](../../../AGENTS.md), [App specification](../../specifications/App/specs.md), [App TDD](../../specifications/App/TDD.md), [PBLE/1](../../specifications/protocol.md), and applicable firmware/release specifications |
18+
19+
This package derives execution views from the strategy. It does not replace normative specifications, expand hardware claims, create GitHub issues, or authorize store/website publication. The strategy file is currently a local document; include it with this package when proposing the documentation for version control.
20+
21+
## Navigation and ownership of information
22+
23+
| File | Canonical responsibility in this package | Update trigger |
24+
|---|---|---|
25+
| [01 — Overview and Scrum framework](01_Overview_and_Scrum_Framework.md) | Product Goal, working agreement, quality and evidence rules | Agreement or governing contract changes |
26+
| [02 — Product roadmap](02_Product_Roadmap.md) | Outcomes, horizons, and conditional investments | Product Goal or strategic priority changes |
27+
| [03 — Milestones](03_Milestones.md) | Evidence-based decisions and admission criteria | New evidence or a milestone decision |
28+
| [04 — Sprint plan](04_Sprint_Plan.md) | Sprint Goal forecasts, calendar, and capacity | Sprint Planning or Sprint Review |
29+
| [05 — Product backlog and stories](05_Product_Backlog_and_Stories.md) | Ordered work, parent/child identities, acceptance criteria, and source traceability | Refinement or changed user evidence |
30+
| [06 — Sprint backlogs](06_Sprint_Backlogs.md) | Candidate tasks, local effort allowances, dependencies, and execution status | Developers select/adapt work during a Sprint |
31+
32+
```mermaid
33+
flowchart LR
34+
Strategy["Strategy revision 1.2"] --> Goal["One Product Goal"]
35+
Goal --> Roadmap["Outcome roadmap and milestones"]
36+
Roadmap --> Product["Ordered Product Backlog"]
37+
Product --> Planning["Sprint Planning"]
38+
Planning --> Sprint["Sprint Goal and Sprint Backlog"]
39+
Sprint --> Increment["Increment meeting Definition of Done"]
40+
Increment --> Review["Sprint Review: inspect evidence"]
41+
Review --> Product
42+
Review --> Roadmap
43+
Sprint --> Retro["Retrospective: improve how we work"]
44+
Retro --> Planning
45+
```
46+
47+
## Product Goal and current baseline
48+
49+
**Proposed Product Goal:** tablet-owning makers can complete useful BLE board work, recover their local work after interruption, and choose PyBLE again for a relevant task using accurately identified app and firmware builds.
50+
51+
| Active outcome | Main planning parents | Evidence of value |
52+
|---|---|---|
53+
| Know what users install | PYB-001; residual PYB-002 only | Reproducible installation guidance and dated channel/build evidence |
54+
| Preserve users' work | PYB-006, supported by PYB-008/009 | Accepted draft survives the specified restart/failure cases without implicit board writes |
55+
| Complete useful repeat tasks | PYB-003/004/011/012; PYB-005 if observed | Task C attempts, later-day useful work, reasons to choose PyBLE, and support effort |
56+
57+
| Baseline fact | Consequence |
58+
|---|---|
59+
| Android open-testing copy correction is complete in PR #33 | Do not replan that correction; identify any new discrepancy separately |
60+
| App source is `0.2.0+8`; Play publicly identifies `0.2.0`; iPad remains external TestFlight beta | Source version does not prove the installed store binary or its source commit |
61+
| Firmware v0.6.1 is published on owner confirmation across five exact profiles | Pending automated results stay pending; no automatic PyBLE Ready badge |
62+
| Issue #24 is closed/superseded | Do not resurrect its old release umbrella as a dependency |
63+
| Editor draft is volatile under [ADR-0010](../../decisions/0010-working-loop-in-memory-document.md) | Close an accepted subset of A-24; do not claim full project persistence or Blocks recovery |
64+
| Lifecycle protections, tutorials, imports, and test tools already exist | Reuse them; refine only observed gaps and the documented persistence gap |
65+
66+
## Applying Scrum to PyBLE
67+
68+
The [2020 Scrum Guide](https://scrumguides.org/scrum-guide.html) is the framework reference. The Product Backlog is ordered by the Product Owner; Developers select and adapt Sprint work. Product Goal, Sprint Goal, and Definition of Done guide the respective artifacts. A Sprint Review inspects progress and informs adaptation; it is not a mandatory release approval meeting. Roadmaps, milestones, user-story notation, and hour allowances below are PyBLE planning practices, not additional Scrum requirements.
69+
70+
| Accountability | Proposed PyBLE arrangement | Assignment state |
71+
|---|---|---|
72+
| Product Owner | One maintainer accountable for the Product Goal, backlog order, and stakeholder tradeoffs | Named person TBD |
73+
| Scrum Master | Facilitates effective Scrum, impediment removal, and sustainable delivery | Named person TBD; any combined responsibility must be explicit |
74+
| Developers | Contributors collectively plan and deliver work, including applicable tests and evidence | Actual availability and skills TBD |
75+
| Stakeholders/contributors | Release owner, board operator, pilot coordinator, instructor, and language reviewer supply expertise/access | These contribution responsibilities do not create extra Scrum accountabilities |
76+
77+
Do not represent a solo-maintainer workflow with missing accountabilities as a fully staffed Scrum Team. Record the practical arrangement and its limits. Role labels in tables are suggestions, not assignments to absent people. A coding agent does not supply independent physical evidence or become the accountable Product Owner.
78+
79+
| Event/practice | Proposed local cadence | Concrete output | Capacity treatment |
80+
|---|---|---|---|
81+
| Sprint Planning | First working day; initially allow 60 minutes | One Sprint Goal, selected items, task plan, named capacity and dependencies | Inside the Sprint's gross hours |
82+
| Daily Scrum | 15 minutes each working day | Developers inspect the Goal and adapt the immediate plan | Inside the Sprint's gross hours |
83+
| Sprint Review | Last working day; initially allow 60 minutes | Inspect usable Increment and evidence with stakeholders; adapt backlog | Inside the Sprint's gross hours |
84+
| Sprint Retrospective | After Review; initially allow 45 minutes | One improvement to apply in the next Sprint | Inside the Sprint's gross hours |
85+
| Refinement | Up to one hour weekly initially, adjusted to need | Split/clarify upcoming items; Developers size their work | Included within available capacity; no separate approval ceremony |
86+
87+
These local durations can change with the team; the Daily Scrum remains 15 minutes. The 14-hour reserve per Sprint includes events, refinement, support, additional qualification, and uncertainty. Do not count those hours again as extra delivery capacity.
88+
89+
## Local readiness and Definition of Done
90+
91+
| Before selection: local readiness aid | Required clarification |
92+
|---|---|
93+
| User outcome or learning question | Named beneficiary, observed problem, bounded in/out scope |
94+
| Governing contract | Specification/ADR and prior approval required for behavior changes; any carried exception visible |
95+
| Acceptance and evidence | Observable scenarios, relevant tests, physical devices when required, evidence location |
96+
| Feasibility | Developers' estimate, actual owner/access, dependencies, safe rollback/recovery |
97+
98+
Readiness is a local refinement aid. It does not replace Sprint Planning or add a formal Scrum commitment. Unknowns can be selected as time-boxed discovery items with their own explicit output.
99+
100+
| Definition of Done: applicable requirement | Evidence required |
101+
|---|---|
102+
| Behavioral scope agrees with the accepted contract | Specification/ADR changed before implementation where required; all selected acceptance scenarios satisfied |
103+
| Behavior is verified | Required `[red]` then `[green]` work, relevant regression checks, and mandatory physical evidence for the selected scope; refactor only while green |
104+
| Repository boundaries hold | DCO-signed commits when committing; no-leak, license, dependency, localization/import, and actual required CI checks as applicable |
105+
| Increment is coherent and usable | Review completed; integration and relevant documentation agree; no unresolved blocking data-loss or unintended-write defect |
106+
| Claims have evidence | Exact artifacts, pass/fail/not-run states, limitations and pending release work recorded truthfully |
107+
| Documentation/discovery scope is complete | Usable reviewed record/guide or agreed findings, source/link checks, and explicit unmet targets; no invented physical results |
108+
109+
This is the proposed package-wide minimum; accepted normative requirements remain binding. Apply it to the selected item rather than treating a source merge as a finished feature. A documentation or discovery item can be Done with a negative finding, while a required physical-installation task cannot be Done if no installation happened. A usable Sprint 1 documentation increment should help an operator or user perform the current workflow; an internal plan alone is not evidence of improved app behavior.
110+
111+
| State distinction | Meaning |
112+
|---|---|
113+
| Source complete | Implementation/review work reached its source milestone; required physical or integration work may still prevent Done |
114+
| Done Increment | Selected acceptance and applicable Definition of Done are met; it can be inspected and used in its declared scope |
115+
| Release admitted | All applicable release-level gates, support matrix, provenance and distribution prerequisites pass |
116+
| Submitted / available / installed | Three different distribution observations, each requiring its own evidence |
117+
118+
Unfinished items return to the Product Backlog for reordering and replanning. Do not count them as Done or convert a blocked result into a pass. A release can happen during any Sprint when its applicable gates pass; recruitment and retention do not block an otherwise qualified maintenance release.
119+
120+
## IDs, evidence, and change control
121+
122+
| Convention | Rule |
123+
|---|---|
124+
| `PYB-001` … `PYB-032` | Existing strategy planning parents; not GitHub issue numbers |
125+
| `PYB-006.1`, `PYB-006.2`, etc. | Derived child items in this package; acceptance is maintained in file 05 |
126+
| `A-24` | Existing broader persistence story; a bounded child does not complete all of it |
127+
| `C1-S1` … `C1-S6` | This cycle's Sprints; distinct from historical App TDD Sprint labels |
128+
| `C1-S1-T01`, etc. | Proposed task rows; not new public contracts |
129+
| `M-01`, etc.; `SG0` … `SG6` | Delivery milestones versus strategy gates; neither replaces CI G0/G1 or C3 firmware gates |
130+
| Item/task status | Proposed → Selected at Planning → In progress → Review → Done; Blocked records a reason/owner; later forecasts remain Proposed |
131+
| Private versus public records | Contact/consent, device identifiers and raw logs remain private/ignored; publish only reviewed aggregate findings and redacted evidence |
132+
133+
When facts or priority change, update the canonical file above and its dependent tables together. Preserve old evidence and dated decisions. New opcode/capability values, hardware support, Ready awards, and publication need their normal specification and authorization paths; none is inferred from this package.
134+
135+
## Source map
136+
137+
| Source | Use and precedence |
138+
|---|---|
139+
| [Strategy revision 1.2](../../planning/PyBLE_Implementation_Plan_and_Strategy_v1.0.md) | Scope, targets, six-Sprint capacity, three outcomes, Ready program and conditional horizons |
140+
| [Public roadmap](../../ROADMAP.md), [README](../../../README.md) | Current capability and distribution baseline |
141+
| [App specification](../../specifications/App/specs.md), [App TDD](../../specifications/App/TDD.md), [ADR-0010](../../decisions/0010-working-loop-in-memory-document.md) | Persistence contract and recorded implementation deviation; consult frozen working-loop scope |
142+
| [Firmware roadmap](../../planning/firmware-v0.6.1-v0.7.0-roadmap.md), [PBLE/1](../../specifications/protocol.md) | v0.7 proposals versus frozen wire behavior; old v0.6.1 publication/#24 wording is historical |
143+
| [Android publication review](../../testing/website/android-open-testing-2026-09-25.md), [v0.6.1 publication record](../../testing/firmware-v0.6.1-publication-2026-09-11.md) | Dated evidence; neither establishes a newly installed binary or missing automated qualification |
144+
| [HIL guide](../../../tests/firmware_tests/hil/README.md), [CI workflow](../../../.github/workflows/ci.yml), [CONTRIBUTING](../../../CONTRIBUTING.md) | Reuse existing tools and gates; actual CI requirements govern merges |

0 commit comments

Comments
 (0)