Skip to content
CS Capstone Handbook

Sprints

Your team has a project partner, a repository, and a list of things to build, and someone has to decide what gets built in the next two weeks. Or a sprint just ended and there was nothing to show at the demo. This page covers how a sprint runs from planning to retrospective, what “done” has to mean for the cycle to work, how to estimate and protect the plan, and when continuous flow with Kanban fits better. It doesn’t cover how to rank the backlog or how to facilitate a retrospective.

A sprint is a fixed-length period in which a team plans, builds, and reviews a small increment of work it can demonstrate. The vocabulary comes from Scrum, whose guide defines sprints as “fixed length events of one month or less”. This page assumes two-week sprints: long enough to finish something you can demo, short enough that a bad plan costs two weeks rather than a month.

Preparing for Your First Sprint

Section titled “Preparing for Your First Sprint”

A real sprint needs a few things in place first. Get them done in your first weeks together, before the first sprint planning:

  • Meet your project partner to understand the problem, the constraints, and what matters most to them.
  • Set up the development environment: repository, CI (continuous integration) pipeline, project board, and communication channels.
  • Draft your working agreement and your Definition of Done.
  • Write initial requirements and turn them into a backlog.
  • Build something, however rough, before the preparation is over.
Project RequirementsHow to gather, write, and manage requirements for your project.

The Sprint Cycle

Section titled “The Sprint Cycle”

Each sprint runs the same four phases: plan, build, review, reflect. The Scrum Guide names them Sprint Planning, the Sprint itself with its Daily Scrum, the Sprint Review, and the Sprint Retrospective. Read it once, because it’s the authoritative definition of the terms your future colleagues will use, and it’s short. It also says Scrum is “immutable”, and that while “implementing only parts of Scrum is possible, the result is not Scrum.”

This page departs from the Guide in places, stand-up frequency among them, so by the Guide’s own definition what it describes isn’t Scrum; Some Truths opens with the reason.

Sprint Planning

Section titled “Sprint Planning”

At the start of each sprint, the team meets to decide what it’ll deliver by the end. The Scrum Guide organizes planning around three topics: why the sprint is valuable, what can be done this sprint, and how the chosen work will get done. For a small team, those become three questions:

  1. What’s the sprint goal? One sentence naming the most valuable thing the team will deliver. The Scrum Guide calls it “the single objective for the Sprint.”
  2. What work will you pull in? Specific items from the backlog (user stories, research questions, experiments, data pipeline steps), sized to fit the hours people have.
  3. Who owns what? Every item has one person responsible for finishing it.

Keep planning to 30 to 60 minutes, which is enough when the backlog arrives ready and the meeting only has to choose, check sizes, and assign. If your planning runs long, look at the backlog first: a team writing and sizing items during planning is doing what the Scrum Guide calls Product Backlog refinement, “breaking down and further defining Product Backlog items into smaller more precise items”, which belongs before planning.

The Sprint Itself

Section titled “The Sprint Itself”

During the sprint, the team builds. Two practices keep it coordinated without a lot of meetings: the stand-up and the sprint board.

A stand-up is a short sync (10 to 15 minutes) where each person says what they did since the last one, what they’ll do before the next one, and what’s blocking them. Scrum’s version, the Daily Scrum, is a 15-minute daily event. The 2020 edition of the Scrum Guide dropped these three questions and lets the team “select whatever structure and techniques they want”, as long as the meeting focuses on progress toward the sprint goal.

Hold stand-ups two or three times a week rather than daily, and adjust once you see what the team needs. Stray et al. (2020) recommend adapting the frequency in the same direction: a team that already communicates well can stop meeting daily if three or four times a week is enough. For larger teams, they suggest posting the answers in writing every day and meeting in person less often. An async stand-up borrows that idea for a small team: a thread in the team’s chat that everyone answers on the days between meetings, or instead of a meeting when schedules don’t overlap.

A stand-up can easily turn into a status report to whoever runs it; run it as coordination between peers instead. In a study of 12 software teams in three companies, the factors that did most to make people dislike the daily stand-up were status reporting to the manager and a meeting people felt was held too often and ran too long, while the factors that did most to make them value it were information sharing and the chance to discuss and solve problems (Stray et al., 2016). Stray et al. (2020) observed that when the facilitator’s behavior made members address the facilitator, the stand-up often became a status-reporting meeting, and when members talked to each other, it tended to become a discussion.

The same authors go further than this page does and recommend dropping the question of what each person has done since the last meeting altogether, putting status somewhere else, such as a visual board, so the meeting’s time goes to what’s ahead and what’s blocked (Stray et al., 2020). If your stand-ups turn into a recital of yesterday’s work, try it for a sprint.

The sprint board is a shared view of what’s to do, in progress, and done. Keep it accurate throughout the sprint rather than tidying it before the review, because the board is what the stand-up reads and what the next planning starts from.

Sprint Review

Section titled “Sprint Review”

At the end of the sprint, the team demonstrates what it finished to the project partner and to anyone else with a stake in the direction, such as a mentor or an advisor. This is the sprint demo, and it answers one question: does the work meet the acceptance criteria and the partner’s expectations?

Show the work itself: running software on real data, a notebook with actual output, a visualization, a benchmark comparison, a written literature synthesis. A description of what you did gives the partner nothing to react to, and their reaction is what the review exists to collect. Ask for explicit feedback, then adjust the backlog based on what you learn.

PresentationsHow to prepare and deliver an effective sprint demo.

Sprint Retrospective

Section titled “Sprint Retrospective”

After the review and before the next sprint starts, the team holds a short retrospective (30 to 45 minutes) on how it worked rather than on what it built. The Scrum Guide gives its purpose as planning “ways to increase quality and effectiveness”, and the retrospectives guide covers formats and facilitation.

Definition of Done

Section titled “Definition of Done”

The Definition of Done (DoD) is the team’s shared agreement on what it means for a piece of work to be finished. The Scrum Guide defines it as “a formal description of the state of the Increment when it meets the quality measures required for the product”, and adds that an item that doesn’t meet it “cannot be released or even presented at the Sprint Review.” Without one, each person’s “done” differs: one means merged, another means merged and tested, a third means it works on their laptop, and the gap surfaces when someone tries to build on the work.

A DoD for a software project might read:

  • Code is merged to the main branch through a reviewed pull request.
  • All tests pass in CI.
  • The feature is deployed to a development or staging environment.
  • Documentation is updated (README, inline comments, API docs where they apply).
  • The project partner has seen the feature or signed off on its acceptance criteria.

A DoD for a research project might read:

  • Notebooks or scripts are committed to the repository and run without errors.
  • Results are reproducible: another team member can rerun the notebook and get the same output.
  • Key findings, parameters, and decisions are documented, in the notebook itself or in a summary document.
  • Datasets are versioned or clearly referenced (source, retrieval date, preprocessing steps).
  • The project partner has reviewed the results and given feedback.

Your project may sit in between, since research projects produce software and software projects include exploratory analysis. Write the DoD that fits your work, and revise it as the project matures: add the deployment step once a staging environment exists, for example.

Team Working AgreementHow a team agrees its Definition of Done.

Estimation and Capacity

Section titled “Estimation and Capacity”

Software estimates tend to be wrong, and in one direction. Moløkken and Jørgensen (2003) reviewed surveys on software effort estimation and found that most projects (60 to 80%) overrun their effort or schedule. Estimate a sprint to keep the team from committing to more than it can finish, and when the estimate misses, expect it to have missed by planning too much.

Estimate each task as small (under a day), medium (one or two days), or large (more than two days), and split every large task before it enters a sprint. The scheme only has to catch a task that won’t fit in a sprint, and three sizes are enough for that.

Estimate together, because a teammate may know why a task is harder than it looks. In planning poker, the team discusses differing estimates and estimates again until they converge. Moløkken-Østvold and Haugen (2007) trialled it in one software project, using it for half the tasks. The group estimates were less optimistic and more accurate than a mechanical combination of the individual estimates for the same tasks, though control tasks estimated by individual experts came out about as accurate as the planning poker tasks.

Capacity is the time the team actually has this sprint, after every other commitment each member has. Count all of it during planning and plan to it, because people predict their own completion times optimistically. Buehler et al. (1994) found people’s predictions too optimistic across a variety of academic and nonacademic tasks, and found that people predicting focused on future scenarios rather than on relevant past experience.

The same study points at the fix: in its fourth experiment, the optimistic bias disappeared when participants were told to connect relevant past experiences to their predictions (Buehler et al., 1994). A team’s past experience is its velocity, roughly how many tasks it finishes per sprint, which you’ll know after two or three sprints. Start each plan from it.

Managing Scope Mid-Sprint

Section titled “Managing Scope Mid-Sprint”

Unexpected work will arrive mid-sprint: a bug that blocks the demo, a clarification from the project partner, a dependency that doesn’t work as documented. When it does, you have two options:

  1. Swap out a planned task of similar size to make room for it.
  2. Leave it for the next sprint, if it isn’t urgent.

Don’t silently add it on top of the plan. The Scrum Guide says that during a sprint “no changes are made that would endanger the Sprint Goal”, while scope “may be clarified and renegotiated” as the team learns more. A swap made in the open keeps the plan realistic and the board accurate; a silent addition makes the sprint miss with nobody able to say why.

If a task turns out much larger than estimated, raise it at the next stand-up, split it, adjust the sprint, and record what happened so the retrospective can look at why the estimate missed.

Kanban: A Complementary Approach

Section titled “Kanban: A Complementary Approach”

Sprints batch work into two-week commitments. Kanban is the alternative built around continuous flow: instead of committing to a batch every two weeks, the team pulls the next highest-priority item whenever someone has capacity. The Kanban Guide defines it as “a strategy for optimizing the flow of value through a process” and names three practices: defining and visualizing the workflow, actively managing the items in it, and improving it. For a small team, those come down to three mechanics:

  1. Visualize the workflow. Use a board with a column for each stage of work (for example Backlog, In Progress, In Review, Done). The Kanban Guide leaves the board’s design to the team.
  2. Limit work in progress (WIP). The Kanban Guide says members “must explicitly control the number of work items in a workflow” and start new work only when there’s a clear signal of capacity, and it leaves the method to the team. This page’s method is a cap on each column: with a WIP limit of 3 on In Progress, nobody starts a new task until one moves on. The cap stops the team from having ten things started and nothing finished, and a column that fills up and stays full shows you where the work is stuck. Atlassian’s page on WIP limits covers setting and tuning them.
  3. Pull, don’t push. People pull work when they have capacity, instead of receiving assignments at the start of a sprint.

When Kanban Works Well

Section titled “When Kanban Works Well”

Consider Kanban when these hold for your team:

  • Everyone pulls work without being asked.
  • The workload is unpredictable, for example partner feedback that reshuffles priorities every few days.
  • The team prefers a steady flow of small deliverables to a batch every two weeks.

Scrumban: The Hybrid

Section titled “Scrumban: The Hybrid”

Scrumban combines the sprint cadence (planning, review, retrospective) with Kanban flow inside the sprint. Corey Ladas, author of the original Scrumban essay, describes it as a way to reach continuous delivery through step-by-step process improvement, with Scrum as the starting point. The name is also used for a steadier hybrid:

  • The team still plans every two weeks and holds a sprint review and a retrospective.
  • Inside the sprint, work flows continuously rather than being frozen into a fixed commitment.
  • WIP limits keep the team finishing work before starting more.

Try the hybrid when the team wants the flexibility of flow but still needs a fixed rhythm for demos and check-ins with its project partner. The sprint boundary supplies the rhythm, and the flow absorbs weeks when members’ schedules are uneven.

What Good Sprints Look Like

Section titled “What Good Sprints Look Like”

At the end of a good sprint:

  • The sprint goal was met, or the team can explain why it wasn’t.
  • Real results were demonstrated to the project partner: running software, notebook outputs, validated findings.
  • The team identified at least one process improvement and committed to it.
  • Every team member made a documented contribution.

At the end of a struggling sprint:

  • Most tasks are “still in progress.”
  • The demo was skipped, or replaced with a summary of what was attempted rather than what was achieved.
  • The same blockers appear sprint after sprint.
  • The retrospective produces the same action items with no follow-through.

When a sprint struggles, look at planning, stand-ups, and retrospective follow-through before asking anyone to work harder. Each item on the second list traces back to one of them: a plan bigger than the team’s capacity, a blocker nobody raised, an action item nobody owned.

Tools

Section titled “Tools”

Pick the smallest set of tools that covers planning, a visible board, and a record of what happened, because every extra tool is one more place the team has to keep current. Treat anything beyond that as optional.

Need Options
Sprint board and backlog GitHub Projects (Preferred), Linear, Jira, Trello
Async stand-up A thread in the team’s existing chat
CI GitHub Actions, GitLab CI/CD
Time tracking (optional) Toggl Track, Clockify

Prefer GitHub Projects when your code lives on GitHub, because a project integrates with the repository’s issues and pull requests, so the board holds the same items the team already works in and there’s no second list to keep in sync.

Best Practices

Section titled “Best Practices”
  • Commit to a sprint goal, not just a task list, because a goal survives a disruption that would break a fixed list.
  • Finish work in progress before starting something new, because the review can show only finished work, and a teammate can build only on a finished piece.
  • Demo to your project partner every sprint, not only at milestones, because feedback on two weeks of work is cheaper to act on than feedback on two months.
  • Timebox stand-ups, and move a problem that concerns only two or three people to a follow-up with them, so the rest of the team isn’t held in someone else’s discussion.

Some Truths About Sprints

Section titled “Some Truths About Sprints”

A two-week sprint on a student team simulates a practice built for people who work on one product full time. Your sprint shares its two weeks with other courses, exams, and a stretch when nobody’s available, so your capacity swings from sprint to sprint in a way a full-time team’s doesn’t. That makes planning the event most likely to feel like a formality, because a plan only predicts well once capacity is stable enough to learn from. Expect the first two or three sprints to be calibration rather than prediction, and don’t conclude the practice is worthless when the first one overruns.

Estimates go wrong when they leave the team. Ron Jeffries, whose Extreme Programming team renamed its “ideal days” to points, writes that he “may have invented story points, and if I did, I’m sorry now”. He argues that tracking actuals against estimates is at best wasteful, that comparing teams on their estimates or velocity is harmful and, for many managers, an irresistible temptation, and that estimates are implicated in management pressure to do more. He would rather slice work small enough not to need estimating. If you track velocity at all, keep it inside the team and use it to answer “did we take on too much?”, because once it’s used to compare teams or assess individuals, the people producing the estimates have every reason to protect themselves instead of estimating accurately. Velocity counts one team’s output in that team’s own units, so it doesn’t compare across teams, and Martin Fowler argues that there’s no reasonable way to measure software productivity at all, because nobody can measure software’s output.

Kanban can be proposed for the wrong reason. When a proposal to switch arrives right after a sprint the team failed to finish, ask whether what’s really being proposed is the removal of the deadline that exposed the problem. If it might be, hold the retrospective on the missed sprint first, and decide on the switch only once you know what made the sprint miss.

Of the four events inside a sprint, the retrospective is the one that feels cheapest to skip. Planning and review produce visible artifacts, so skipping them feels like skipping work; the retrospective produces a conversation, so skipping it feels like saving an hour. Keep it anyway, because it’s the only scheduled moment where the person experiencing a process problem can name it before it costs the team a demo.

Finally, the whole framework is a means. The Agile Manifesto is four value statements and twelve principles, much smaller than the industry built on top of it. The principles say nothing about story points or burndown charts, and on iteration length they ask only for working software delivered “from a couple of weeks to a couple of months, with a preference to the shorter timescale.” Adapt the events to your team, and keep what the principles do ask for: working software delivered often, and a regular moment when the team reflects on how to become more effective.

Sprints in Industry and Academia

Section titled “Sprints in Industry and Academia”

Scrum comes from Ken Schwaber and Jeff Sutherland, who first co-presented it at the OOPSLA conference in 1995, according to the Scrum Guide’s own history. The Kanban Guide traces Kanban to the Toyota Production System and says the practices now called Kanban for knowledge work “mainly originated on a team at Corbis in 2006.”

Few practitioners report running a whole project in one consistent style. Kuhrmann et al. (2022) surveyed practitioners internationally and, of 556 data points, found only 83 (about 15%) that ran every project discipline consistently agile, consistently traditional, or consistently balanced; the rest reported different degrees of agility across disciplines, with a general tendency toward hybrid development. They also found that the practices a team selects have a stronger effect on how agile a discipline is than the methods it uses. Expect one-week sprints, four-week sprints, pure Kanban, and home-grown hybrids in industry, and judge each by the practices it runs rather than by its label.

Mahnic (2012) describes an undergraduate capstone in which student teams worked as Scrum Teams, implementing user stories defined by a domain expert who played the Product Owner, with data collected on the work completed, adherence to plans, and estimation ability; student surveys were overwhelmingly positive.

References

Section titled “References”
  • Stray, V., Moe, N. B., and Sjøberg, D. I. K. (2020). Daily Stand-Up Meetings: Start Breaking the Rules. IEEE Software. https://doi.org/10.1109/MS.2018.2875988
  • Stray, V., Sjøberg, D. I. K., and Dybå, T. (2016). The Daily Stand-Up Meeting: A Grounded Theory Study. Journal of Systems and Software. https://doi.org/10.1016/j.jss.2016.01.004
  • Moløkken, K., and Jørgensen, M. (2003). A Review of Software Surveys on Software Effort Estimation. International Symposium on Empirical Software Engineering (ISESE). https://doi.org/10.1109/ISESE.2003.1237981
  • Moløkken-Østvold, K., and Haugen, N. C. (2007). Combining Estimates with Planning Poker: An Empirical Study. Australian Software Engineering Conference (ASWEC). https://doi.org/10.1109/ASWEC.2007.15
  • Buehler, R., Griffin, D., and Ross, M. (1994). Exploring the "Planning Fallacy": Why People Underestimate Their Task Completion Times. Journal of Personality and Social Psychology. https://doi.org/10.1037/0022-3514.67.3.366
  • Kuhrmann, M., Tell, P., Hebig, R., Klünder, J., Münch, J., Linssen, O., Pfahl, D., Felderer, M., Prause, C. R., MacDonell, S. G., Nakatumba-Nabende, J., Raffo, D., Beecham, S., Tüzün, E., López, G., Paez, N., Fontdevila, D., Licorish, S. A., Küpper, S., Ruhe, G., Knauss, E., Özcan-Top, Ö., Clarke, P., McCaffery, F., Genero, M., Vizcaíno, A., Piattini, M., Kalinowski, M., Conte, T., Prikladnicki, R., Krusche, S., Coşkunçay, A., Scott, E., Calefato, F., Pimonova, S., Pfeiffer, R.-H., Schultz, U. P., Heldal, R., Fazal-Baqaie, M., Anslow, C., Nayebi, M., Schneider, K., Sauer, S., Winkler, D., Biffl, S., Bastarrica, M. C., and Richardson, I. (2022). What Makes Agile Software Development Agile? IEEE Transactions on Software Engineering. https://doi.org/10.1109/TSE.2021.3099532
  • Mahnic, V. (2012). A Capstone Course on Agile Software Development Using Scrum. IEEE Transactions on Education. https://doi.org/10.1109/TE.2011.2142311

Additional Readings

Section titled “Additional Readings”

Sources and further reading

Activities that exercise this