How a Sprint Is Structured
A standard sprint follows a predictable structure. Sprint planning opens the sprint: the team selects user stories from the product backlog, discusses acceptance criteria, and commits to a scope they believe is achievable within the sprint duration. The commitment is to the scope, not to a deadline, which is already fixed. Daily standups provide brief synchronisation: what was completed, what is being worked on, and whether anything is blocking progress. The standup is a coordination mechanism for the team, not a status report to management. Sprint review closes the sprint: completed work is demonstrated to stakeholders, feedback is gathered, and the product owner formally accepts or rejects completed items against their acceptance criteria. The sprint retrospective follows: the team reflects on how the sprint went, identifies what to keep doing and what to change, and produces concrete improvements for the next sprint. Backlog refinement prepares user stories for future sprints by adding detail, splitting large stories, and estimating complexity.
Sprint Length Trade-offs
Sprint length is a team decision with meaningful trade-offs. One-week sprints produce faster feedback loops and force tighter scope discipline. Teams get more opportunities to adjust direction based on what they learn. The cost is higher ceremony overhead per sprint: planning, review, and retrospective take roughly the same time whether the sprint is one or two weeks, so one-week sprints spend a higher fraction of time in ceremony. Two-week sprints are the most common choice because they balance feedback frequency against overhead. They allow enough time for non-trivial features to be designed, built, and tested properly within a single sprint. Four-week sprints are generally too long for startup contexts because the feedback loop is too slow and the risk of building in the wrong direction for a month before review is too high. For AI MVP development at SpeedMVPs, the effective sprint duration is the full 2-3 week delivery window, meaning the entire MVP scope is delivered in one or two sprints with daily progress visibility.
Velocity and Capacity Planning
Sprint velocity is the measure of how much work a team completes per sprint, expressed in story points or similar units. Tracking velocity over multiple sprints creates a predictive model: if a team's average velocity is 24 points per sprint and a backlog contains 120 points of estimated work, the team will take approximately five sprints to complete it. This is useful for planning but must be interpreted carefully. Velocity is a planning tool, not a performance metric. Comparing velocity across teams, or pressuring a team to increase velocity arbitrarily, produces inflated estimates rather than faster delivery. Capacity planning adjusts the team's available hours in a sprint for known absences, meetings, and non-development work. A two-week sprint with a four-person team does not provide 320 person-hours of development time. Accounting for meetings, code review, documentation, and interruptions, effective development time is typically 50-65% of nominal capacity.
Sprints for AI Product Development
AI product development has characteristics that require sprint planning adaptations. AI features have uncertain timelines: a prompt engineering task may take 2 hours or 2 days depending on how quickly satisfactory performance is achieved. This non-determinism makes story point estimation less reliable for AI-specific tasks. Approaches that help include time-boxing AI research and prototyping tasks explicitly, with an acceptance criterion of 'decision made on approach' rather than 'feature complete', and separating AI spike tasks (exploration) from implementation tasks (delivery) in sprint planning. AI features also require evaluation, which must be scoped into the sprint. A sprint that delivers an AI feature without testing its quality against representative inputs has not actually completed the feature. Build evaluation time into sprint capacity from day one.
Definition of Done for AI Features
The Definition of Done is a shared standard that determines when a user story is complete. For traditional features, this typically includes: code reviewed, tests written, deployed to staging, acceptance criteria verified, and product owner accepted. For AI features, the Definition of Done should add: evaluated against a representative test set and meeting the agreed accuracy threshold, edge cases documented and handled, prompt version logged and version-controlled, latency measured and within accepted bounds, and cost per request estimated and within the project budget model. Without these AI-specific criteria, a sprint can close with AI features that look done but fail in production because quality was never measured. Defining these criteria at the start of an AI project, rather than discovering they were omitted after launch, prevents the most common AI product quality failures.
How SpeedMVPs Uses Sprints
SpeedMVPs delivers AI MVPs in a compressed sprint structure: a 2-3 day discovery and scoping sprint followed by a 2-3 week delivery sprint. The discovery sprint produces a prioritised scope, defined acceptance criteria, and an agreed metrics baseline. The delivery sprint produces a production-deployed MVP with analytics, AI quality evaluation, and documentation included. Daily progress updates keep clients informed without requiring them to manage sprint ceremonies directly. This structure applies Lean Startup discipline, shipping something real to measure, within a predictable commercial and timeline framework. All code is transferred on delivery and pricing is fixed from GBP 8,000.