Flux7 Agile Runbook — Notes & Key Concepts
Source: Flux7 Agile Runbook (91 pages, internal Flux7 document, September 2019) Full document: Google Drive —
Brainforge > Resources > Delivery References > Flux7 Agile Runbook.pdfRelevance: Flux7 was a proserv/DevOps consulting firm with a mature agile delivery model. Their workflow from SOW to engagement closeout maps closely to how Brainforge delivers, with Linear replacing Trello and our service hierarchy replacing their Epic-from-SOW model. Added: 2026-03-10
Why This Matters to Brainforge
Flux7 solved the same problem Brainforge is solving: how do you make a professional services delivery process repeatable, trackable, and learnable across multiple client engagements? Their model:
- SOW epics copy verbatim into the project board — our
linear-template.mddoes this - Engagement lifecycle from SOW signing to closeout is fully scripted — our
implementation-plan.mddoes this - Portfolio hierarchy (Initiative → Epic → Story → Task) matches our chain — our chain adds a Phase (Milestone) layer
- Each engagement has a working agreement, DoR, and DoD defined at kickoff — actionable for our engagement kickoffs
Key Concepts
Agilist (Delivery Lead) High-Level Workflow
The full lifecycle from prospect to closeout:
| Step | Description | Brainforge equivalent |
|---|---|---|
| SOW Estimation | Agilist facilitates estimation of min/max stories per epic | DRI scopes offering using implementation-plan.md |
| SOW Preparation | Select template, fill in epics from estimation, get approved | CSO builds SOW from offer.md + implementation-plan.md |
| SOW Acceptance | Signed SOW triggers staffing and board setup | Engagement kickoff; clone Linear canonical project |
| Capacity Planning | Staff the team from bench or rolloffs | Assign DRIs in Linear project |
| Assessment | Discovery/audit phase if applicable | Phase 0 in our implementation-plan.md |
| Board Creation | Copy epics verbatim from SOW; set Working Agreement, DoR, DoD | Clone linear-template.md into client project |
| Cadence Setup | Set recurring Sprint Planning, Standup, Review, Retro times | Weekly sync, standup, sprint reviews per SOW |
| Backlog Refinement | 3 days before sprint: identify and size stories | Weekly backlog grooming |
| Sprint Planning | Tasks that provide most value; half-day/day granularity | Linear sprint planning |
| Daily Standup | Burndown, impediments, swarming, story splits | Daily standup |
| Sprint Review | Present Done work to client engineers for acceptance | Client sync / demo |
| Sprint Retrospective | Rotate themes; put findings into next sprint immediately | End of sprint retro; update implementation-plan.md |
| Knowledge Transfer | Concentrated KT meeting between team and stakeholders | Handoff phase; training sessions |
| Engagement Closeout | Close board if no extensions | Final sign-off; retro on canonical template |
Portfolio Hierarchy
Flux7’s hierarchy maps almost directly to our atomic chain:
| Flux7 level | Our equivalent |
|---|---|
| Initiative | Service Line (Linear Initiative) |
| Epic | Deliverable (Linear Epic) |
| Story | Ticket (Linear Issue) |
| Task | Sub-task (Linear sub-issue) |
| (Flux7 has no phase layer) | Phase = Linear Milestone (our addition) |
Key difference: Flux7 phases are implicit in sprint planning. We make them explicit as Linear Milestones because our fixed-scope engagements have clear phase gates (Phase 0 sign-off, Phase 1 demo, Phase 2 acceptance).
SOW Types
Flux7 mapped SOW types directly to board templates. Their principle: epics in the SOW copy verbatim into the board. This is the exact pattern our linear-template.md implements — the canonical project pre-populates the epics so there’s no translation loss between what was sold and what gets built.
SOW types Flux7 recognized:
- Assessment (audit/discovery only)
- Assessment + Implementation
- Implementation only
- Ongoing (retainer/maintenance)
These map to our delivery model tags: fixed-scope (assessment or impl) / hybrid (assessment + impl) / retainer.
Working Agreement, Definition of Ready, Definition of Done
Flux7 set these collaboratively at engagement start:
- Working Agreement (WA): Norms the team agrees to (communication, hours, escalation). Brainforge equivalent: kickoff checklist + engagement norms.
- Definition of Ready (DoR): What must be true before a story enters a sprint (e.g. acceptance criteria written, no open questions). Brainforge: gate criteria in
linear-template.mdfor each phase. - Definition of Done (DoD): What must be true for a story to be Done (e.g. code reviewed, tested, documented). Brainforge: acceptance criteria in the SOW +
sop.mddelivery notes.
Sprint Ceremonies (cadence)
| Ceremony | Frequency | Duration | Purpose |
|---|---|---|---|
| Sprint Planning | Weekly or bi-weekly | 1–2h | Select stories for sprint; tasks half-day to 1-day granularity |
| Daily Standup | Daily | 15 min | Burndown, impediments, swarming |
| Sprint Review | End of sprint | 1h | Present Done work to client; get acceptance or feedback |
| Sprint Retrospective | End of sprint | 1h | What went well, what to improve; findings → next sprint |
| Backlog Refinement | 3 days before planning | 1h | Size and prioritize upcoming stories |
Engagement Closeout
Flux7’s engagement closeout steps (from Appendix):
- Ensure all stories are Done or formally deferred
- Final knowledge transfer session with client
- Close the board (archive)
- Retro on the engagement (what to improve for next time)
- Confirm whether there are extensions or expansions
Brainforge version: Final sign-off in SOW, retro to update implementation-plan.md and linear-template.md, archive the Linear project, mark engagement as complete in the EP audit.
Estimation Approach
Flux7 used story points (Fibonacci: 1, 2, 3, 5, 8, 13) with Reference Stories as calibration anchors. They explicitly discouraged equating story points to hours.
For Brainforge: our implementation-plan.md uses effort estimates in hours per role (e.g. “Managing Lead: 20h · Senior Engineer: 80h”) for SOW pricing purposes. Story points are for sprint-level planning within a project, not for SOW scope — keep these separate.
Dungeons (Spike equivalent)
Flux7 called focused problem-solving sessions “Dungeons” — a meeting with client stakeholders to unblock a sticky issue. The Brainforge equivalent is an ad-hoc deep-dive session; log the outcome as a meeting note in knowledge/clients/{client}/meeting-notes/.
What to Borrow vs. Adapt
| Flux7 practice | Borrow as-is | Adapt | Skip |
|---|---|---|---|
| Epics copy verbatim from SOW to board | ✓ (our linear-template.md) | ||
| Portfolio hierarchy (Init → Epic → Story → Task) | ✓ | Add Phase/Milestone layer | |
| Working Agreement at kickoff | ✓ | ||
| Definition of Ready / Done | ✓ | ||
| Backlog refinement 3 days before planning | ✓ | ||
| Sprint retrospective findings → next sprint | ✓ | Also update canonical templates | |
| Engagement closeout checklist | ✓ | ||
| Story points for all estimation | Hours for SOW pricing, points for sprint planning | ||
| Trello-based boards | Linear | ||
| ”Game Days” (break code on purpose) | Not relevant for our engagements |