Agile & Delivery Cycles
How MasterFabric plans sprints, manages backlogs, and ships incremental value.
Agile & Delivery Cycles
How MasterFabric plans sprints, manages backlogs, and ships incremental value.
We use agile delivery to ship working software in predictable cycles. Sprints are typically 1-2 weeks, with continuous integration and frequent demos. This page explains our approach to planning, execution, and retrospectives.
Why agile?
Agile lets us adapt to feedback quickly, reduce risk through incremental delivery, and keep stakeholders aligned. Every cycle produces deployable work.
Sprint Structure
| Phase | Duration | Focus |
|---|---|---|
| Planning | 1-2 hours | Review backlog, prioritize stories, estimate capacity. |
| Execution | 1-2 weeks | Daily standups, pairing, code reviews, CI/CD. |
| Review | 1 hour | Demo to stakeholders, gather feedback. |
| Retrospective | 30-60 min | What went well, what to improve, action items. |
Key Practices
1. Backlog Management
- User stories in GitHub Issues with acceptance criteria and labels (feature, bug, tech-debt).
- Prioritization based on business value, risk, and dependencies.
- Refinement sessions mid-sprint to prep the next cycle.
2. Daily Standups
- 15 minutes max: What did I do? What will I do? Any blockers?
- Async option for distributed teams — written standups in Slack/GitHub.
- Follow-up happens outside standup to keep it short.
3. Code Reviews & CI/CD
- Every PR is reviewed before merge.
- Automated tests run on each commit.
- Deployments to staging after merge; production on schedule or tag.
4. Demos & Feedback
- Each sprint ends with a demo of working features.
- Stakeholders provide feedback; adjustments go into the backlog.
- No slides — we show real software.
5. Retrospectives
- What went well? What didn't? What will we change?
- Action items tracked in GitHub and reviewed next sprint.
- Blameless culture — we focus on systems, not people.
Fixed vs. iterative scopes
Some projects have a fixed scope (time & materials or fixed bid). We still use agile cycles, but we track progress against the original plan and communicate changes early.
When We Adjust
- Shorter cycles (1 week) for fast-moving projects or MVPs.
- Longer cycles (3 weeks) for complex features or when integration testing takes time.
- Kanban instead of sprints when priorities change frequently or there's no clear release cadence.