Cycle Buddies Development Operating Model
Roles
You — Business Analyst
- Facilitate stakeholder conversations and capture requirements
- Bring refined requirements, decisions, and open questions to me
- Review and sign off on what I produce
- Escalate blockers or ambiguities back to stakeholders
Me — Solutions Architect + Developer + Tester
- Translate approved requirements into architecture decisions
- Write and iterate on code
- Write and run tests (unit, integration, basic E2E)
- Flag technical risks, constraints, or trade-offs back to you
The Workflow
Stakeholders → You (BA) → Me (Architect/Dev) → Review → Ship
↑ |
└───────── Feedback Loop ───────────┘
Phase 1 — Discovery You bring me: a requirement, user story, or open question from stakeholders. I produce: architecture options with trade-offs, a recommendation, and any clarifying questions for you to take back.
Phase 2 — Design Once a direction is agreed, I produce: a high-level design (data model, API contracts, component breakdown). You review it against stakeholder intent before I write any code.
Phase 3 — Build I write the code in agreed chunks (feature by feature). Each chunk includes: the implementation, inline documentation, and basic tests. You review the output against the requirement — not the code quality, but whether it does what was asked.
Phase 4 — Test & Verify I run tests and report results. You confirm acceptance against the original requirement. If it doesn’t pass your check, we iterate before moving on.
Phase 5 — Retrospect After each feature or sprint, you flag anything that needs re-examining with stakeholders. I flag any technical debt or architectural drift.
Communication Conventions
| You say | I do |
|---|---|
| ”Here’s a new requirement” | Produce architecture options first, no code yet |
| ”Approved, build it” | Write code + tests |
| ”Stakeholder changed their mind on X” | Assess impact, propose the smallest safe change |
| ”Is this feasible?” | Give you an honest answer with trade-offs, not just yes |
| ”Bug / not working as expected” | Debug, fix, re-test, explain what went wrong |
Guardrails
- No code before design sign-off — I won’t start building until you’ve confirmed the approach is right for the stakeholders
- You own requirements, I own implementation — if something is technically awkward, I’ll say so, but I won’t silently change what was asked
- One source of truth — the BRD on your site is our baseline; changes should be reflected there before I build them
- Incremental delivery — we build and verify feature by feature, not everything at once
Suggested Starting Point
Given the BRD you shared, a sensible first sprint would be:
- Stack decision — I propose a tech stack, you validate it fits LCC’s constraints (hosting, budget, existing skills)
- Data model — I design the schema from the BRD, you verify it covers all stakeholder needs
- Auth + registration (UC-1) — the foundation everything else depends on
The Model - waterfall on requirements gathering, agile on delivery.
Stakeholders → You (BA) → Full Requirements Doc → Me → User Stories → You Review → Release Plan → Build
You do the full BA job upfront — facilitating workshops, resolving conflicts, getting sign-off on the complete requirements. You hand me a finished requirements document. I then do the decomposition into user stories, group them into releases, and you review before any code is written.
What You Hand Me
A completed requirements document containing:
- Business context — who the users are, what problem is being solved
- Functional requirements — what the system must do (your BRD already has this)
- Non-functional requirements — performance, security, compliance
- Constraints — hosting, budget, timeline, existing systems
- Priorities — what’s critical for launch vs. nice to have
Your existing BRD is already a solid foundation for this.
What I Produce Back
For each set of requirements I’ll generate:
User stories in standard format:
As a [user type]
I want to [do something]
So that [I get this value]
Acceptance Criteria:
- Given / When / Then
Grouped into releases — typically:
| Release | Theme | Rationale |
|---|---|---|
| R1 — MVP | Core journeys only | Get live, migrate data |
| R2 — Safety & Compliance | Moderation, GDPR tooling | Legal obligations |
| R3 — Engagement | Feedback loops, reporting | Measure impact |
| R4 — Enhancements | Future features | Growth |
With dependencies called out — so you know why a story is in R2 and not R1.
Your Review Step
Before I write a line of code you would:
- Check every story maps back to a requirement (traceability)
- Validate the release groupings make sense to stakeholders
- Add, remove, or re-prioritise stories
- Sign off the release plan
Only after sign-off does build begin, release by release.
The Ongoing Cycle
Requirements sign-off
↓
I generate stories + release plan
↓
You review + approve
↓
R1 build → R1 review → R1 ship
↓
R2 build → R2 review → R2 ship
↓
(requirements changes fed back in as amendments, not rewrites)
Ready to Start
Your BRD from the site is detailed enough to begin. If you want, share the finalised requirements document (or confirm the BRD is complete and signed off) and I’ll produce:
- A full user story backlog
- A proposed release plan with rationale
- A traceability matrix mapping each story to a BRD requirement
Just say the word.