Scope agreed before the first commit, a working build every two weeks, and nothing in front of your users until you approve it. Here is each step.
01 · Before the build
Alignment before the first commit
Scope, timeline, and expectations are settled before any code is written, so the build starts from one shared plan.
from first call to kickoff, with scope, cost, and dates agreed
Discovery session
We start with the goals, the constraints, and what the product has to do on day one.
- Requirements
- Technical feasibility
- Timeline estimate
- Resourcing and tooling
Stakeholder interviews
I talk to the people who own the business and the people who will use the product.
- Business interviews
- User research
- Pain points
- Competitor review
Documentation
Scope, deliverables, and cost go on paper, so everyone signs off on the same plan.
- Software requirements (SRS)
- Statement of work (SOW)
- Work breakdown (WBS)
- Execution plan and budget
Sign-off and kickoff
Agreements are reviewed and signed, and the first sprint goes on the calendar.
- Contract review
- Budget approval
- Timeline confirmed
- Project kickoff
02 · Sprints
Two weeks, one working build
Every sprint runs from a Monday to the Friday after next and ends with features you can test in UAT. This is a typical one.
- Sprint planning, Mon week 1
- Development, Tue week 1 to Tue week 2
- Code review, Wed week 2
- Testing and QA, Thu week 2
- UAT deploy, Fri week 2
At sprint close
Sprint closure report
What shipped, what got blocked, and why.
Progress tracker
Timeline, budget, and milestones, updated.
Next sprint plan
Priorities and goals for the next two weeks.
Weekly check-ins
A standing sync to review progress, clear blockers, and agree on what matters next.
Sprint health checks
Velocity, blockers, and capacity are tracked through the sprint, so slippage shows up early.
Priorities can move
Anything not yet started can be reordered at the next planning session.
When a sprint slips. If a task will not finish inside a sprint, you hear about it before the review, not at it. It either rolls into the next sprint or the sprint is extended, depending on what matters more to you.
03 · Environments
Four environments, one gate
Every change is tested more than once on its way to your users, and the last step waits for your approval.
Local
My workstation
Features are built and tested first.
Development
Integration
Merged work runs together, with automated tests on every push.
UAT
Acceptance testing
You click through each feature and approve it.
Your sign-offProduction
Live
Approved releases reach real users with zero downtime.
04 · Scope changes
When the scope changes
New ideas are welcome mid-build. Each one is sized and agreed before it touches the sprint.
You raise it
New work that sits outside the agreed SOW.
I size it
Effort, complexity, and the effect on the current sprint.
We decide
Fit it into this sprint, or treat it as a formal change request.
It ships
Inside the sprint, or as its own scoped and approved change.
Minor adjustment
Small enough to fit the current sprint without moving its commitments.
For example
- UI tweaks
- Copy changes
- Small bug fixes
- Configuration updates
Absorbed into the current sprint
Formal change request
Larger work that gets its own estimate and your approval before it starts.
For example
- New features
- Architecture changes
- Third-party integrations
- Major refactoring
Scoped and approved as its own change
Tell me what you want to build.
I will come back with how the first two weeks would look for your project.