Our agile app development process runs in fixed two-week sprints. Every sprint ends with three things: software you can install, a budget report and a plain answer on whether the date still holds. You spend three to four hours per sprint with us, and if something is going to slip, you hear about it in week two, not month four.
Below is what happens in each sprint and what you receive at each step. It also covers how much of your calendar it takes. The rhythm is the same whether we are building an MVP or maintaining an app that has been live for years.
How our agile app development process runs, day by day
A sprint is ten working days. The team stays the same for the whole sprint, typically three to six people: developers, a QA engineer and a product lead who is your main contact. A fixed team means a fixed cost per sprint, and that is what makes the budget predictable.
Day 1: Planning (60 to 90 minutes of your time)
We start with a call where you and our product lead agree what the sprint will deliver. We bring a ranked backlog with estimates, and you confirm the order or change it. The output is a one-sentence sprint goal, plus a list of stories with acceptance criteria you have read.
We plan to about 80% of the team's measured capacity. The other 20% absorbs bugs, review feedback and the surprises every codebase produces. In our experience, planning to 100% is the fastest way to miss a sprint.
Days 2 to 9: Build, with a written update every day
The team builds, reviews each other's code and tests as it goes. Every pull request needs a code review and passing automated tests before it merges. Nothing counts as done until QA has checked it on real devices, not just a simulator.
Each afternoon you get a written update in a shared Slack or Teams channel. It covers what moved, what is blocked and any question we need you to answer. If a question blocks work, we mark it as blocking so it does not sit for three days.
Around day 5, the product lead checks progress against the plan. If a story is running long, you hear about it that day, with options. You do not find out at the demo.
Day 10: Demo (about 60 minutes)
We show working features on a real build, not slides or design files. For mobile apps, the same build reaches your phone through Apple's TestFlight or a Google Play internal test track before the call ends. You try it, push on the edges and tell us what feels wrong.
Anything that missed its acceptance criteria is shown as not done. We never demo half-built features as finished. That habit is exactly how a project looks green for months and then misses by a quarter.
Day 10: Retro (internal, 30 minutes)
After the demo, the team runs a short review of its own process. One or two concrete changes go into the next sprint, such as splitting stories smaller or adding a test for a bug that keeps coming back. You get the outcome as one line in the sprint report.
You can see how a project with us runs, mapped to your own roadmap, before you commit to anything.
What you receive at the end of every sprint
- A working build. It installs on your devices, or runs on a staging URL for web apps. The code lives in your repository from day one.
- Release notes. What shipped, what did not and the known issues, in plain language.
- A burn report. Cost this sprint, total spent to date, and remaining budget against remaining scope.
- An updated forecast. Stories are re-estimated, and the projected finish is given as a range rather than one hopeful date.
- A risk log. The three to five things most likely to hurt the date, each with a named owner.
What it costs you in time
- Planning: 60 to 90 minutes.
- Daily updates and questions: 5 to 10 minutes a day, or roughly an hour per sprint.
- Demo: about 60 minutes, plus 15 minutes trying the build on your own.
That comes to three to four hours every two weeks for your decision owner. Other stakeholders usually join the demo only. If you cannot give that time, tell us early, because slow answers cost more schedule than slow code.
How the budget stays visible
Because the team is fixed, each sprint costs roughly the same. For illustration, say a sprint costs $25,000. After four sprints you have spent $100,000, and the burn report shows exactly how much of the planned scope that bought.
The forecast uses velocity, which is the amount of estimated work the team actually finishes per sprint. We average the last three sprints, not the best one. If the remaining scope needs eight sprints and your budget covers six, you see that gap while you still have room to act.
We give the finish as a range, for example sprint 9 to sprint 11. The range usually tightens after three or four sprints, once velocity settles. A single date that early would be a guess dressed up as a commitment.
What happens when scope changes or work slips
Something always changes. A competitor ships a feature, a user test shows a confusing flow, or an API turns out worse than its docs. The process does not stop change, but it forces a clear choice about it.
New work goes into the backlog, never into the current sprint, unless it is a production fix. At the next planning call you pick one of three options.
Swap
Drop a story of similar size from the plan. The date and budget stay the same. This is the right call most of the time.
Cut
Remove scope outright, often a nice-to-have, to pull a slipping date back. You ship less, but on time.
Extend
Add sprints. The date and budget move by an amount you see in the burn report before you agree. Nothing extends quietly.
Why two weeks, not one or four
The Scrum Guide caps a sprint at one month. We have tried lengths across that range and settled on two weeks for most product work.
- One week: fast feedback, but the fixed meetings take twice the share of team time. Many features also cannot reach a demoable state in five days.
- Two weeks: enough time to finish a meaningful feature. A bad estimate costs at most ten working days.
- Four weeks: less meeting overhead, but a wrong turn can burn a month before anyone sees it. That gap is where surprise delays hide.
What this process will not fix
Two-week sprints make problems visible. They do not make them disappear. Three things still cause delay, and we flag them at kickoff.
- Slow decisions. If a blocking question waits a week for an answer, that week is gone. We agree on one decision owner on your side before sprint 1.
- App store review. Review times vary, so release sprints carry buffer. We build to the App Store Review Guidelines from the first sprint, not the last.
- Third-party systems. Payment providers, health record systems and legacy APIs move at their own speed. We test risky integrations in the first two sprints, so you learn early if one will be slow.
FAQ
How long is a typical agile sprint?
Sprints usually run one to four weeks, and the Scrum Guide caps them at one month. Two weeks is a common default because it balances feedback speed against meeting overhead. We use two weeks for most product work.
How do I know if an app development agency is on track?
Ask for a working build and a burn report every sprint, not status slides. Compare finished work against spend, and watch whether the forecast range is narrowing. If you only ever see designs or percentages, you cannot tell.
Can I change features in the middle of an agile project?
Yes, and you should when you learn something. The change goes into the backlog and is planned at the next sprint. You then choose to swap out other work, cut scope or add sprints, with the cost shown up front.
