Sprint in Mobile Development: Essence, Duration and Planning

What is a Sprint in Development?

Sprint is a timebox of fixed duration at the end of which the team delivers a ready-to-use product increment. The concept of a sprint is the foundation of Scrum, but it is also used in other Agile frameworks. In mobile development, an increment is a build of the application that can be installed on a device, tested and shown to stakeholders. A sprint cannot be extended — if tasks are not completed, they are moved to the next sprint.

The key feature of a sprint is fixed duration. The team does not change the sprint goal after approval. This provides predictability: stakeholders know when they will receive the result. Within the sprint, the team decides how to distribute the work. The Scrum Master protects the team from external interference — new tasks are not added to the current sprint. According to the Scrum Guide 2025, this is the only way to maintain a sustainable development pace.

A sprint consists of four mandatory events: Sprint Planning, Daily Scrum (daily synchronization), Sprint Review (demonstration of the result), Sprint Retrospective (process analysis). In between is the main work: task implementation, testing, code review. Duration of each event is directly proportional to the sprint length: for a 2-week sprint, Planning is 4 hours, Review is 2 hours, Retro is 1.5 hours, Daily is 15 minutes. Total rituals take about 8 hours per sprint — 10% of the team's working time.

Scrum Rituals of a Sprint

Scrum rituals (ceremonies/events) are structured team meetings within the sprint. Sprint Planning at the beginning, Daily Scrum every day, Sprint Review and Retrospective at the end. All events have a timebox. The Scrum Master ensures compliance with the timebox and focus. The entire Scrum team participates in each ritual: Product Owner, Scrum Master, developers. The exception is Daily Scrum (only developers participate, PO and SM are optional).

The connection of rituals to sprint stages: Planning sets the direction (what and how we do it), Daily synchronizes (who is doing what, what blockers exist), Review shows the result (what was done, what was not), Retrospective improves the process (how to make the next sprint better). Skipping retrospective is the most common team mistake: when deadlines are tight, Retro is sacrificed first. This leads to process stagnation and repetition of the same mistakes. Research by Scrum.org (2025) shows that teams conducting Retro every 2 weeks improve velocity 35% faster.

Sprint Planning: Iteration Planning

Sprint Planning is a team meeting at the beginning of the sprint where it is determined what will be done and how. The Product Owner presents priority tasks from the Product Backlog. The team estimates capacity (available time considering vacations, meetings, tech debt) and selects tasks it can complete during the sprint. The result of Planning is Sprint Goal and Sprint Backlog (list of tasks). The Sprint Goal is formulated as a short sentence: “Implement the order screen and payment integration via SBP.”

Velocity is the team's speed measured in story points per sprint. Average over the last 3-5 sprints. According to Scrum.org (2025), a team of 5 mobile developers (3 Android + 2 iOS) has a velocity of 25-40 SP per 2-week sprint. Planning uses velocity as an upper bound — they take 10-15% less to account for unforeseen tasks (code review, incidents, helping other teams). Capacity vs Velocity: capacity is “person-hours,” velocity is “story points.” Capacity accounts for vacations, sick leave, meetings. Typical loss rate is 25-30% of working time spent on non-code activities.

Planning is divided into two parts: “what” (PO describes tasks, team clarifies) — 2 hours, and “how” (team decomposes and estimates) — 2 hours. For mobile projects, “how” discusses: compatibility with Android/iOS versions, need for feature flags, impact on APK/IPA size, new permissions. Planning Poker technique is used for estimation: each developer gives their estimate in story points (1, 2, 3, 5, 8, 13). A discrepancy of more than 2 units triggers discussion of reasons. This reveals hidden risks at the planning stage, not in the middle of the sprint.

Sprint Execution: Daily Standup and Tracking

Daily Scrum (Standup) is a daily 15-minute meeting for team synchronization. Each participant answers three questions: “What was done yesterday?”, “What am I planning to do today?”, “What blockers do I have?” The Daily is not a status report for the manager but a tool for team self-organization. If during the Daily it turns out that two developers are working on the same task — that is a signal for reorganization. Important: The Daily does not solve problems but identifies them — a separate meeting is called after Daily to resolve them.

Scrum Board (sprint board) is a visualization of the Sprint Backlog. Columns: To Do / In Progress / In Review / Done. Each task moves across the board. Burndown Chart is a graph of remaining work by sprint day. The ideal burndown is a straight line from total SP to 0. The actual burndown is a step chart accounting for task completion. A falling burndown (below the ideal line) means we are behind schedule. Problem signal: if less than 30% of tasks are completed by mid-sprint — adjustment is needed. Risks may not have been accounted for or tasks were overestimated.

For mobile development, sprint tracking is affected by specific factors: build time (Android project build in CI can take 30+ minutes), waiting for App Store / Google Play moderation (if a build needs to be released to testers via TestFlight), compatibility with different devices (testing on 10+ models takes time). Tip: allocate 1 day of buffer at the end of the sprint for final testing and release build assembly. This reduces the risk of an incomplete sprint by 40% according to Mind the Product (2025).

Sprint Review and Retrospective

Sprint Review is a demonstration of the increment to stakeholders. The team shows a working application build, not slides. Duration is 2 hours for a 2-week sprint. The Product Owner checks compliance with Acceptance Criteria. Stakeholders provide feedback that may affect the Product Backlog. Review is not a report but a dialogue: stakeholders can ask questions and suggest changes. Key rule: Sprint Review is about the product, not the process. Show what was achieved, not how it was done.

Sprint Retrospective is an internal team meeting to analyze the past sprint. Format: Start Doing (what to start doing), Stop Doing (what to stop doing), Continue Doing (what to continue doing). Duration is 1.5 hours for a 2-week sprint. Retrospective is a safe space for discussing problems. Rule: technical details are not discussed in Retro (there are technical meetings for that). Only process, communication, tools, culture. The Scrum Master facilitates the meeting and ensures each participant speaks.

The result of Retrospective is 1-3 improvements for the next sprint. If the team identified the problem “Code review takes too long” — action item: “Set SLA for review — 4 hours. If review is not done on time — the developer reminds in Slack.” Action Items must be specific, measurable and assigned to a specific person. According to Atlassian (2025), teams that follow through on their Retro action items improve velocity by 15-25% over 3-4 sprints. Those who do not — stay in place.

How to Choose Sprint Duration

2 weeks is the standard for mobile development. The optimal balance between predictability and flexibility. Enough time to: plan, implement 3-5 medium features, test, show results. 1 week is for teams with high process maturity and CI/CD. Requires quick decisions, minimal bureaucracy. Suitable for early-stage startups that need to experiment quickly. Disadvantage: high overhead on rituals (Planning + Review + Retro every week = 7.5 hours).

3-4 weeks are for complex projects involving hardware integration (wearables, IoT, BLE devices), long store moderation or major migrations (e.g., transitioning from RxJava to Coroutines). Long sprints provide more time for testing but increase the risk of the “waterfall effect” — the team loses Agile flexibility. Scrum Guide Recommendation: do not exceed 1 month. If a sprint is longer, there will be too much context at Review and stakeholders will not be able to provide quality feedback.

Typical Sprint Problems

Problem 1: Scope Creep. In the middle of a sprint, the Product Owner adds a new “urgent and important” task. The team agrees — and the sprint fails. Solution: Sprint Goal is a contract. Any change requires revisiting the Sprint Goal, which is only possible in emergency cases. The new task goes to the Product Backlog and to the next sprint. If the task is truly critical — the old Sprint Goal is canceled, the sprint is re-planned, but this is an exception, not a practice. Scope creep frequency of more than once in 3 sprints is a sign of a weak Product Owner.

Problem 2: Incomplete Tasks. By the end of the sprint, 50% of tasks are In Progress, 20% In Review, only 30% Done. Reasons: overestimated capacity, underestimated complexity, unplanned bugs. Solution: analyze the reason at Retro. If you systematically cannot keep up — do not increase the number of tasks at Planning, but decrease them. Teams that take 20% fewer tasks show a higher completion rate (80%+ vs 50-60%). Checklist for Planning: for each task, check Acceptance Criteria, Definition of Ready and dependency with other tasks.

Problem 3: Formal Retro. The team holds Retro just for show — 15 minutes, generic phrases, no action items. Solution: change the format of each Retro. Methods: Sailboat (what slows down, what speeds up), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Assign action items with deadlines and owners. At the beginning of the next Retro, check the completion of previous action items. According to Atlassian (2025), teams that use different Retro formats generate 50% more useful insights.