App review sits between code complete and shipped, and most agile advice ignores it. The release train, the two ceremonies we kept, and why you estimate integrations.
Agile on a mobile team breaks in a way it does not break on the web, and the reason is the store.
On a web product, "ship it Friday" is a deploy. On mobile, shipping means a build, a review queue you do not control, a staged rollout, and a population of users who may not update for weeks. You can run perfect two-week sprints and still have three different versions of your app live at once. Most agile advice written for web teams quietly assumes that problem away.
We run 4 to 8 week engagements at Codestreaks, kickoff to live deployment, across 30+ production projects since 2024. That cadence works, but not because we run textbook Scrum. It works because we cut most of the ceremony and kept two things.
The single most useful change we make on mobile projects is to stop pretending the sprint ends when the code is done.
A mobile increment is not done when it merges. It is done when it is in front of users, and the distance between those two events is measured in days you do not control. App review can take hours or it can take a week. A staged rollout that surfaces a crash gets halted. A user on an old OS version never sees any of it.
So we plan against a release train, not a sprint. The train leaves on a fixed date. Work that is finished and tested gets on it. Work that is not, waits for the next one. What we never do is hold the train for a feature, because holding it once teaches everyone that deadlines are negotiable and the next slip is bigger.
The practical effect is that "what is in this release" becomes a real conversation with a real cutoff, and scope negotiation happens before the freeze instead of during review.
Most mobile teams we inherit are running four ceremonies and getting value from one and a half.
We keep two.
A short daily. Fifteen minutes, standing, and the only question that matters is what is blocked. Not status. Status is in the board. Blockers are what a daily is actually for, and on mobile the blockers are distinctive: waiting on a provisioning profile, waiting on a backend endpoint, waiting on a test device, waiting on review. Every one of those is a thing someone else can unblock in ten minutes if they hear about it.
A retro that changes something. Every second week, and it produces exactly one change to how we work. Not a list of eight. One. A retro that generates a list nobody actions is a meeting that teaches the team retros are theatre.
What we dropped: separate backlog grooming (fold it into planning), and sprint review as a distinct ceremony from the demo we are already doing with the client. Two meetings that mostly restated each other.
We are not anti-process. We are against process that nobody would miss. If you want the fuller picture of how a build runs end to end, our mobile app development process guide walks the phases.
This is where mobile estimation goes wrong most often, and it is the same root cause that distorts pricing.
Teams point stories by how much UI there is. A screen with a form and a list is a 3. A screen with a chart is a 5. Then the "simple" settings screen turns out to require a token refresh flow against an auth service that expires sessions differently on iOS and Android, and the 3 eats a week.
Point the integration. When a story touches an external system, ask what happens when that system is slow, down, or lying, and estimate that. The UI is usually the cheap part.
We have watched this single change take a team from missing most sprints to hitting them, without anyone working differently. They were just finally estimating the thing that took the time.
On a cross-platform team, "done" has to mean done on both platforms or your velocity is a fiction.
We have seen boards where iOS work and Android work are separate tickets. It feels organised and it hides drift. Android trails by a sprint, then two, and by the time anyone notices, the platforms have diverged enough that a shared fix is no longer shared.
One ticket, both platforms, tested on both, or it is not done. Velocity drops on paper the week you introduce this rule, and everyone panics. It has not actually dropped. You were counting half-finished work as finished. We covered the technical side of keeping a single codebase honest in our cross-platform development guide.
A rule we hold with more conviction than most: the team's test device should be a mid-range Android handset that is three years old, not the newest iPhone.
Every developer's daily driver is fast, new, and on office wifi. That device will never show you the thing your users are experiencing. The three-year-old Android on a weak cellular connection shows you within thirty seconds.
This is not a ceremony, but it changes sprint outcomes more than any ceremony we have tried. Performance problems get caught during development rather than in a support ticket two releases later.
Rope Access Logbook shipped in eight weeks. It replaced a paper logbook that industrial rope access technicians fill in at height, often with no signal, and which carries real legal weight when an auditor asks for it.
The agile lesson from that project was about the demo cadence. We showed the founder working software every single week, and in week three he watched a technician try the offline flow and immediately said the sync confirmation was not obvious enough. Someone at height, in gloves, needed to know their entry was saved without squinting. That is not a bug a spec catches, and it is not a bug a designer catches in a studio. It surfaced because a real user touched a real build in week three rather than week seven.
His summary afterwards: "Codestreaks took our rough idea and turned it into a real product in just 8 weeks. The way they built it saved us months of headaches down the road."
The weekly build in front of a real user is the part of agile we would defend hardest. Almost everything else is negotiable.
Agile will not save a project with an unclear owner. If three stakeholders can each change priorities and none of them can overrule the others, no cadence rescues that. We ask who the single decision-maker is before kickoff, and we have declined work where the answer was a committee.
It also will not fix an app nobody wants. Shipping fortnightly means you find out faster, which is genuinely valuable, but iterating quickly toward the wrong thing is still the wrong thing.
Yes, with one structural adjustment. Plan against a release train rather than a pure sprint boundary, because app store review and staged rollouts sit between "code complete" and "users have it" and you do not control that gap. Teams that ignore it end up with sprints that are technically green and releases that keep slipping.
Two weeks suits most teams. One week rarely leaves room for a proper testing pass on multiple devices. Three weeks is long enough that priorities drift mid-sprint. The sprint length matters far less than having a fixed, respected release date.
One codebase, one definition of done covering both platforms, a weekly build in front of a real user, and estimates driven by integration complexity rather than screen count. That combination is what makes our 4 to 8 week engagements land on schedule.
No. Separate tickets let one platform quietly fall behind, and the two implementations drift until a shared fix stops being shared. One ticket, done on both, tested on both.
Decide in advance what justifies an out-of-band release, and write it down before you need it. Crashes and data loss ship immediately. Everything else waits for the next train. Making that call under pressure, with no prior agreement, is how teams end up shipping five hotfixes in a fortnight.
Written by the Codestreaks team in Austin, TX. The cadence described here is the one we actually run: 4 to 8 week engagements, two engagements per quarter, weekly working builds. The eight-week Rope Access Logbook timeline, the week-three offline sync finding, and Chad Dubuisson's quote are from that engagement. Drafting is AI-assisted and every post gets a human editing pass against our real delivery record. Practices we have not run ourselves are not presented here as if we had.
If your mobile releases keep slipping and you cannot tell whether it is process or scope, we are happy to look at it. Free 30-minute call, reply within two business days.
More on how we run builds on our mobile app development service page, or start a project.
A serial maker of SaaS products and AI agents, I’ve built and launched 10+ tools, grown products to thousands of users, and taken multiple ventures. I share the process what works, what breaks, and how builders can ship faster and smarter. Previously a data scientist at a Big Four consulting firm.
