A working feature is only part of a finished capstone. Your schedule also needs testing, guide feedback, the report, presentation preparation and submission checks. Build a capstone project timeline from your department’s deadlines and the hours your team can actually work, then use the example and copyable tracker below to organize the work.
Jump to: Seven steps · 12-week example · Copyable tracker · Fix delays · FAQs
What should a capstone project timeline include?
A capstone project timeline is a dated plan connecting required deliverables to tasks, owners, dependencies and assessment deadlines. It should show estimated effort, review checkpoints and completion evidence so the team can assess progress and revise expected finish dates.
A task is work, such as testing a return transaction. A deliverable is its output, such as the application and test record. A milestone marks a checkpoint, such as prototype acceptance; the milestone itself has no duration, although preparing and reviewing the prototype takes time.
Requirements vary by programme. For example, IISc’s M.Tech Online guidelines require an approved proposal and work plan for that individual-project programme. The three-person plan below is a separate illustration. Follow your own handbook rather than adopting another institution’s rules or this article’s example duration.
Build your timeline in seven steps
1. Record deadlines and work backward
List proposal, internal review, report, presentation and viva dates separately. Record each cut-off’s time, time zone and submission channel. Add exams, placement interviews, holidays and unavailable lab periods.
Work backward: submission needs checked files; checked files need corrections; corrections need feedback; feedback needs a reviewable draft and results.
In the example below, the assumed cut-off is 28 March 2027 at 5 pm IST. Target upload is 27 March, corrections run in Week 11, and the complete draft reaches the guide by 10 March for an assumed 11–13 March review window. These are planning assumptions, not confirmed appointments.
Agree review turnaround early. The University of Minnesota’s capstone guidance highlights that arranging a professor meeting can itself require advance planning.
2. Break deliverables into reviewable tasks
Map assessment criteria to outputs: design, implementation, analysis, test evidence, report and presentation. Then divide each output into smaller tasks—a work breakdown structure.
Replace “finish backend” with “create and retrieve a loan, reject invalid requests, and record tests.” If commitments are still unclear, define your capstone scope first.
3. Estimate effort against each person’s availability
Effort is working time; duration is elapsed calendar time. An eight-hour task takes four working days at two available hours daily, assuming no additional waiting.
For this illustrative three-person team:
3 students × 6 hours/week × 12 weeks = 216 gross person-hours.
Subtract 24 hours of exam-related unavailability, 24 of coordination/reviews and 24 held as contingency. That leaves 144 planned task-hours: 48 per student.
These are assumptions, not recommended universal allocations. Do not subtract meetings twice if your availability already excludes them. A sufficient team total does not prove that a specialist owner can finish their assigned work.
These hours show how to balance a schedule; they do not establish how quickly your team can build the prototype. Confirm the interface, required tests, permitted reusable components and team skills. Compare estimated and actual effort during an early setup or implementation task, then re-estimate remaining work if the assumptions do not hold.
4. Arrange dependencies before drawing chart bars
A finish-to-start dependency means one task must finish before another starts. A schema may need agreed record rules; integration needs working modules; conclusions need evaluated results.
Test uncertain assumptions early: dataset access, a sensor, an unfamiliar dependency or the intended demonstration machine. Parallel work is feasible only when prerequisites and people are available.
The tracker below demonstrates this with setup and record rules finishing on Tuesday, allowing schema creation to begin on Wednesday.
5. Schedule review activity and acceptance checks
Record the reviewer, evidence, review window and expected decision date. Use observable checks such as “issue and return update availability correctly in the recorded cases.”
Keep a guide’s waiting time separate from student effort. A three-day review window need not mean three days of student work. Continue independent tasks while waiting; dependent corrections must wait for the decision.
Leave actual acceptance dates blank until review occurs. A scheduled milestone is not proof of approval.
6. Include evaluation, writing and usable contingency
Draft background, methods and design sections while working. Add actual test results and interpretation when available. Use the project report guide to check documentation requirements.
Planned testing, normal defect correction and report revisions are estimated tasks. Contingency covers additional uncertain work. Reserve both hours and calendar windows before the affected deadline; unused hours after submission cannot rescue an earlier review.
7. Update forecasts without erasing the baseline
The baseline is the original agreed schedule. The forecast is the current expected schedule. Review remaining effort, blockers, evidence and owner availability weekly, then revise forecast dates where necessary.
Use consistent statuses: Not started, In progress, Blocked, Ready for review and Accepted. Store evidence links and record why dates changed.
If a task reaches its allocated hours without meeting its completion check, record the unfinished work, re-estimate it and check dependent dates and owner capacity. Use contingency for additional uncertain work, and agree changes to assessed commitments with your guide.
A 12-week capstone project timeline example
This is an illustrative software plan, not an observed FileMakr delivery. It covers 4 January–28 March 2027: 12 Monday–Sunday weeks. A handles requirements/documentation, B implementation/setup, and C evaluation/presentation. All three review one another’s work.
The assumed small library prototype includes seeded accounts, book records, role permissions, issue/return, availability checks and simple search. Payments, notifications and external integrations are excluded. Actual academic requirements may need substantially more work.
The estimates assume the team already knows its chosen stack and can use the intended local environment. Account separately for learning, extra academic depth or restrictions on reusable components before adopting the plan.
At a glance: Weeks 1–2 define scope and prepare the design/setup; Weeks 3–8 build, test and package the core workflows; Week 9 evaluates the frozen build; Week 10 assembles results and guide feedback; Week 11 corrects and rechecks; Week 12 packages, rehearses and submits. Writing and test planning also occur alongside implementation.
Read the example in three passes: check each person’s available hours, follow the work and review sequence, then copy the tracker with your own dates. The same owner/calendar assumptions apply throughout; the separate delay example later uses a different Monday–Friday calendar.
Calendar: each student has one gross hour Monday–Saturday. In Weeks 4 and 8, Wednesday–Saturday are unavailable, leaving Monday–Tuesday. Coordination uses Saturday’s hour in Weeks 1, 2, 3, 5, 6, 7, 9 and 10. Contingency reserves Thursday–Friday in Weeks 5, 7 and 10, and Friday–Saturday in Week 11.
Thus each owner loses eight hours to unavailability, uses eight for coordination and holds eight as reserve: 72 − 8 − 8 − 8 = 48 task-hours.
Capacity summary: hours per student per week. For grouped rows, the figures apply separately to every listed week; they are not totals for the whole group.
| Weeks | Gross | Unavailable | Coordination | Reserve | Tasks |
|---|---|---|---|---|---|
| 1, 2, 3, 6, 9 | 6 | 0 | 1 | 0 | 5 |
| 4, 8 | 6 | 4 | 0 | 0 | 2 |
| 5, 7, 10 | 6 | 0 | 1 | 2 | 3 |
| 11 | 6 | 0 | 0 | 2 | 4 |
| 12 | 6 | 0 | 0 | 0 | 6 |
The table allocates those hours. Each cell is an owned work package; split it further when needed. The hours column applies to each person, not the whole team.
| Week/dates, 2027 | A: requirements/report | B: implementation/setup | C: evaluation/presentation | Task hours each |
|---|---|---|---|---|
| 1: 4–10 Jan | A1: rubric, problem, scope | B1: setup-risk prototype | C1: background sources, evaluation outline | 5 |
| 2: 11–17 Jan | A2: record rules 2 h; design notes 3 h | B2: setup 2 h; schema 3 h | C2: acceptance cases | 5 |
| 3: 18–24 Jan | A3: requirements/design draft | B3: seeded login and catalogue | C3: schema checks, coverage review | 5 |
| 4: 25–31 Jan | A4: loan/return rules | B4: role restrictions | C4: login/catalogue tests | 2 |
| 5: 1–7 Feb | A5: methodology draft | B5: issue/return workflow | C5: loan test data and cases | 3 |
| 6: 8–14 Feb | A6: design explanation, diagrams | B6: search and module integration | C6: issue/return tests | 5 |
| 7: 15–21 Feb | A7: report progress update | B7: known defect corrections | C7: integrated-test preparation | 3 |
| 8: 22–28 Feb | A8: evaluation protocol | B8: freeze/package test build | C8: finalise evaluation data | 2 |
| 9: 1–7 Mar | A9: background/method draft | B9: reproducible setup instructions | C9: evaluate frozen build | 5 |
| 10: 8–14 Mar | A10: add results; check references | B10: evaluation defect corrections | C10: results narrative, slide outline | 3 |
| 11: 15–21 Mar | A11: report corrections, Mon–Thu | B11: setup-document corrections, Mon–Thu | C11: regression tests 3 h Mon–Wed; peer review 1 h Thu | 4 |
| 12: 22–28 Mar | A12: final checks and upload | B12: archive/setup pack; rehearsal | C12: final slides; rehearsal | 6 |
| Total per person | 48 h | 48 h | 48 h | 48 |
Team total: 48 + 48 + 48 = 144 planned hours. No row exceeds the owner’s remaining weekly task capacity. This checks the example’s allocation, not whether the estimates will hold in a real project.
Each owner’s later package follows their earlier package. Important cross-owner prerequisites are grouped below; a plus sign means all listed inputs are needed.
| Work | Required sequence |
|---|---|
| Design/setup | A2a rules + B2a setup → B2b schema → B3 |
| Core workflows | B3 → C4 tests; A4 rules + B4 permissions → B5 |
| Evaluation preparation | B5 + C5 cases → C6 tests → B7 fixes; B6 + B7 → B8 |
| Results | A8 + B8 + C8 → C9 → A10, B10 and C10 |
| Final checks | B10 → C11 regression checks; A11 + B11 → C11 peer review → final checks/upload |
The IDs ending in a or b are subtasks; the tracker explains their parent packages. Planned feedback discussions use coordination hours. C’s Week 11 peer review is charged separately within C11’s four task-hours.
The complete draft is assembled by Wednesday 10 March using Week 9’s results. The guide reviews it on 11–13 March; waiting time adds no student task-hours. In Week 12, complete the archive and slides by Wednesday, then use the remaining sessions for rehearsal and submission.
A12’s six hours include three hours of final file checks Monday–Wednesday, two hours of rehearsal Thursday–Friday, and Saturday’s final hour split between 30 minutes of rehearsal and 30 minutes for the actual upload and confirmation. B and C use their final Saturday half-hour for their own rehearsal notes while A uploads. No extra task-hour is added. Upload by Saturday 27 March; the Sunday cut-off remains a calendar margin, not another planned workday. If upload needs longer, revise the allocation rather than assuming extra capacity.
Review milestones and evidence
| Marker/date | Planned reviewer | Evidence required | Actual acceptance |
|---|---|---|---|
| M1: 9 Jan | Guide, if agreed | Scope, rubric mapping, initial plan | Leave blank |
| M2: 16 Jan | Guide/assigned peer | Record rules, schema, test cases | Leave blank |
| M3: 20 Feb | Guide, if agreed | Core workflow demo and current test record | Leave blank |
| M4: 13 Mar | Guide, if agreed | Draft feedback and correction list | Leave blank |
| M5: 18 Mar, 3 pm IST | Student C, reviewing A11/B11 | Report/setup checklist, regression record, unresolved issues | Leave blank |
In Week 11, A and B each use 10–11 am IST Monday–Thursday for their four-hour correction packages. C uses three hours Monday–Wednesday for regression tests, then reviews their ready outputs 2–3 pm IST on Thursday 18 March. This asynchronous peer check requires no extra A/B attendance. Friday–Saturday, 19–20 March, remain contingency for each student.
The three-hour testing and one-hour review split is illustrative. If outputs, test results or the reviewer are unavailable, revise the forecast. Any additional corrections need explicit remaining-effort estimates and usable capacity.
If a review or estimate changes, revise the forecast. For research, replace coding packages with access approvals, instrument piloting, data collection and analysis. For hardware, include procurement, lab bookings and calibration. Obtain required permissions before the activity they govern.
Copyable capstone timeline tracker
Copy these tables into a shared document or spreadsheet. In a spreadsheet, combine the fields into one sheet if preferred. This Week 2 extract uses the example’s five task-hours per person and one-hour daily sessions.
ID legend: B2 is the Week 2 work package, split into B2a (setup) and B2b (schema). A2 splits into A2a (record rules) and A2b (design notes). Use subtask IDs in dependencies: B2b needs B2a and A2a, not its own parent B2. The subtasks replace their parent’s effort; do not add both totals.
| ID | Task/owner | Effort | Prerequisite | Baseline start–finish | Forecast start–finish |
|---|---|---|---|---|---|
| B2a | Verify setup / B | 2 h | M1 | 11–12 Jan | 11–12 Jan |
| A2a | Define record rules / A | 2 h | M1 | 11–12 Jan | 11–12 Jan |
| B2b | Create schema / B | 3 h | B2a, A2a | 13–15 Jan | 13–15 Jan |
| A2b | Write design notes / A | 3 h | A2a | 13–15 Jan | 13–15 Jan |
| C2 | Prepare acceptance cases / C | 5 h | M1 | 11–15 Jan | 11–15 Jan |
| Your ID | Your task / name | Estimate | IDs | Dates | Dates |
All dates in this extract are in 2027. B2a and A2a finish Tuesday; B2b then uses Wednesday–Friday. A2b and C2 have different owners and can overlap it. Saturday’s coordination hour is outside these task estimates.
| ID | Completion evidence | Initial status | Planned reviewer | Actual finish / acceptance |
|---|---|---|---|---|
| B2a | App/database start from recorded steps | Not started | Assigned peer | Blank / blank |
| A2a | Records, rules and examples documented | Not started | Guide/peer, as agreed | Blank / blank |
| B2b | Script creates agreed tables and constraints | Not started | Assigned peer | Blank / blank |
| A2b | Design explanation matches agreed rules | Not started | Guide/peer, as agreed | Blank / blank |
| C2 | Each agreed workflow has expected outcomes | Not started | Assigned peer | Blank / blank |
| Your ID | Evidence/link | Status | Name | Dates when known |
Add remaining effort, blocker, change reason and next check date as work proceeds. Assign an actual reviewer rather than leaving the role label indefinitely.
How to update the timeline when work falls behind
Recalculate dependent dates and owner availability before assuming every delay moves submission. The critical path is the dependency sequence controlling project finish. Float describes available scheduling flexibility.
In this separate simplified example, Monday–Friday are working days and holidays are ignored. The successor needs both the listed predecessor and a second prerequisite that finishes on Wednesday 3 March 2027. Its earliest baseline start is therefore Thursday 4 March. It starts on the next working day after all prerequisites finish; no owner conflict or additional waiting is assumed here.
| Item | Baseline | Revised forecast |
|---|---|---|
| Listed predecessor finishes | Mon 1 Mar 2027 | Thu 4 Mar 2027 |
| Second prerequisite finishes | Wed 3 Mar | Wed 3 Mar, unchanged |
| Successor starts | Thu 4 Mar | Fri 5 Mar |
| Successor finishes, two-day duration | Fri 5 Mar | Mon 8 Mar |
The listed predecessor initially finishes on Monday 1 March. Because the other prerequisite finishes on Wednesday 3 March, this predecessor can finish up to Wednesday without delaying the successor’s earliest Thursday start: two working days of free float.
Finishing on Thursday 4 March uses that flexibility and delays the successor to Friday 5 March. Its two-day duration then ends Monday 8 March, one working day later than the baseline Friday finish. Submission moves only if the downstream chain has no further usable flexibility; check other paths and owner conflicts too. This is a local dependency example, not a calculated critical path for the entire twelve-week plan.
Record the cause, remaining work and decision. Move genuinely independent tasks where capacity exists; request guide approval before dropping assessed commitments. If review feedback is late, update the correction window and escalate the deadline risk promptly.
Common capstone scheduling mistakes
| Mistake | Correction |
|---|---|
| Drawing overlapping bars for one busy owner | Check daily and weekly allocations |
| Counting reserve as planned testing time | Estimate testing separately; protect uncertainty capacity |
| Marking work “90% done” repeatedly | Record remaining effort and missing evidence |
| Overwriting original dates | Preserve baseline; revise forecast and reason |
| Adding late features without retesting | Estimate the whole change and agree scope decisions |
For stronger reviews, keep evidence beside the relevant task and rehearse the intended setup before the final week. Ask a teammate to follow the setup instructions without verbal assistance; record any corrections as real work.
Frequently asked questions
How long should a capstone project timeline be?
Use your programme’s assessment calendar. Twelve weeks is this article’s example, not a universal requirement. An eight-week plan is feasible only if the required work, resources and available hours support it.
How much contingency should I keep?
Reserve hours according to uncertainty and leave calendar windows where they can be used. This example holds 24 team-hours across four weeks. That assumption is not a recommended percentage for every project.
How do I plan a capstone as a solo student?
Schedule all tasks against your own weekly capacity. Implementation and writing can alternate, but you cannot perform both simultaneously. Include external review waiting time and reduce optional scope when estimates exceed your available hours.
How do I make a Gantt chart for a capstone?
Enter owned tasks, estimates, dates and dependencies first, then display their durations as calendar bars and milestones as markers. Check the working calendar and owner conflicts before accepting overlapping bars as feasible.
Which tool should I use for a capstone project timeline?
A shared spreadsheet is sufficient when it holds the required fields and someone maintains it. Choose a tool your team can update consistently; a sophisticated chart cannot repair missing estimates or prerequisites.
How often should I update the timeline?
Review it weekly and after significant delays, scope decisions or feedback. Update forecast dates, remaining effort and blockers while retaining the original baseline and actual completion evidence.
Plan your next reviewable milestone
Copy the tracker, enter your next required review and check the work against each person’s available hours. Take the evidence and unresolved assumptions to your guide before accepting the schedule.
If you are planning software and still need to understand a workflow, explore FileMakr’s project demonstrations before estimating its implementation. Use resources in line with your institution’s requirements and explain the work you submit.
