How we use a Google Sheet to pace a competency-based software engineering term

April 22, 2026

The row I keep coming back to in the monthly progress tab is October 2025: two CUs, forty-one study hours logged, one new Elden Ring spinoff that came out the second week of the month. September had been eight CUs. November recovered to six. October was the dip, and the dip had a name, and the name was a video game.

The sheet did not tell us not to buy the game. It told us, the following Sunday, that we were not on pace for a December 2027 graduation anymore. Those are different jobs. A planner that tells you what to do is a coach. A planner that shows you the row where you fell off is a mirror. I only know how to build the second one.

The thing the portal won't tell you

I've been pacing a competency-based term alongside a friend finishing his BS in Software Engineering. He's a working data analyst doing coursework in the evenings and on weekends, no prior CS degree, no generous transfer credit, no six-month leave of absence to sprint. His target is December 2027 and he's not the kind of student who posts "I finished in eleven months" screenshots. He's the kind who opens the portal on a Sunday night, sees the green progress bars, and has no idea whether green means "on pace" or "behind."

That is the problem with the program's built-in tools, and it's the reason we built the spreadsheet. The portal tells you what you've done. It does not tell you whether you're doing it fast enough to finish when you said you would. Those feel like the same thing until you're eighteen months in and realize they never were.

What we built

A Google Sheet. Five tabs. Nothing clever.

The Course Tracker is one row per course in his degree plan. Course code, course name, CU value, status, start date, pass date, days to complete. Data structures and algorithms took thirty-one days. Web development foundations took six. Operating systems took thirty-eight and he's still a little annoyed about it. Day-counts on specific courses are load-bearing — they let us pattern-match against Reddit threads and what other students in the program say about the same course. "Thirty-one days on data structures" is portable. "I passed my data structures class" is not.

The Dashboard is the page we open each week. Total CUs completed vs. remaining, current term progress, the velocity number, the projected graduation date. The projection updates every time he passes a course, which means the projection is sometimes brutal. Right now it reads February 14, 2028. His target is December 15, 2027. That's the gap the rest of the sheet exists to close.

The Pace Calculator is where behavior changes. It asks for a target graduation date and returns the CU-per-week number he'd need to maintain from today onward. It also recomputes when he takes a week off (the required pace goes up) or when he clears a three-CU course in ten days (it drops). The feedback loop is small and immediate, which turns out to matter more than the accuracy of the calculation. Humans are bad at interpolating between "I fell behind this week" and "my graduation moved." The sheet does the interpolation.

The Monthly Progress tab is where the Elden Ring row lives. Month, CUs completed, study hours logged, courses passed, and a free-text notes column where he writes down what happened. October 2025 says "new RPG dropped mid-month." That's the only documentation of the dip, and it's enough. The point of the notes column isn't analysis. It's making the row un-lie-aboutable six months later when we're trying to predict the next dip.

The Pre-Assessment Tracker logs his pre-assessment score on every course that has one, plus which competency areas he was weak in before starting. On the data structures course he scored well on trees and graphs and poorly on sorting, so he studied sorting. That's not a productivity hack. It's the thing the portal was built for, buried three clicks deep in the program's interface, which is why we copied it into a spreadsheet where it'd get looked at.

The two numbers that matter

Everything in this sheet resolves to a comparison between two numbers.

Current velocity is how many CUs he's closed per week, averaged over the last thirty days. We use a rolling window because a weekly average is noisy. A hard course can eat three weeks of work and produce zero CU movement, which looks like catastrophic slowdown but is a reasonable tempo for operating systems. Thirty days smooths that. It sits in column K of the Course Tracker. Right now the cell reads 1.8.

Required velocity is how many CUs he needs per week from today forward to hit the target date. It's computed from one of the simplest formulas in the file — remaining CUs divided by weeks remaining until the target. Right now that cell reads 2.1.

The entire CBE planning problem collapses to the difference between those two numbers. 1.8 vs. 2.1. Three-tenths of a CU per week. Over ten weeks that's three CUs, which is most of a class. If we ignore the gap for a month, we lose a class worth of schedule and the target date moves. If we close the gap even halfway, the target date holds.

Every other metric we tracked became noise. Study hours per day. Practice problems attempted. Textbook pages read. They all moved without predicting anything. We deleted those columns around month two. Velocity and required velocity are the signal. Everything else was craft debt.

What we got wrong

We set the original target at June 2027. Eleven months, aggressive, pulled from a Reddit thread about someone who finished a competency-based degree in under a year. After one term of data, the pace calculator said June 2027 required 3.4 CUs per week. His velocity was 1.5. The math didn't care how motivated he was.

We moved the target to December 2027, which pushed required velocity down to 2.1 — a number he could plausibly hit by adding about four study hours a week, which is a real change instead of a magical one. The lesson: if required velocity is more than 1.5x current velocity, the plan is wishful and the calendar will tell you so inside a term.

The other thing we got wrong was assuming courses had uniform difficulty. The first version of the pace calculator divided remaining CUs by remaining weeks and produced a single number. That number was useless, because three CUs of technical writing is not three CUs of operating systems. The current version weights each remaining course by a 1–3 difficulty estimate, pulled from pre-assessment scores and Reddit consensus, and projects finish dates off the weighted total. The first version predicted December 2026 for a workload that turned out to be December 2027 on the nose. Being wrong that early in a useful way is its own kind of planning.

What the sheet changed about Sunday nights

He does the weekly review on Sunday nights. Coffee that went cold around the time I started pulling the velocity numbers from column K, conure chirping at something in the yard, a half-watched episode of something on the second monitor. I look at the gap between 1.8 and 2.1. He looks at next week's schedule. One of us says a number and the other says whether the number is okay. That's the whole meeting. It takes about eleven minutes.

Before the spreadsheet, the Sunday review was "how'd the week go." That question has no answer, so the review had no teeth. Now the review is "did the velocity number move the right direction," which has exactly one answer — yes, no, or the course he's in is a grinder and we'll know by next Sunday.

If you want ours

I cleaned up a version of the sheet and put it on Gumroad as the Competency-Based Degree Planner. Nine dollars. It has the five tabs described above, formulas wired up, and a starter difficulty scale you can overwrite with your own estimates. If you'd rather build your own, the column list in this article is the whole blueprint — Course Tracker, Dashboard, Pace Calculator, Monthly Progress, Pre-Assessment Tracker, with current velocity as a rolling thirty-day average in column K and required velocity as remaining CUs divided by weeks to target. The formula takes about twenty minutes to write. The habit of looking at it takes about two terms.

The sheet won't change the time to graduation. What it changes is whether the student gets to see the gap between where they are and where they said they were going, early enough to do something about it. December 2027 is still the target. February 2028 is still the current projection. We've got a plan for the thirty hours of study per week it'll take to close them, and the plan fits in one row of column K.

Final thought

The October 2025 row is still sitting there in the monthly progress tab. Two CUs, forty-one hours, "new RPG dropped mid-month." Nobody deleted it. Nobody apologized for it. It's just the row where the pace broke, which is how we know what a broken pace looks like the next time it happens.

Competency-Based Degree Planner

The Google Sheet with five tabs pre-built for CBE pacing — all formulas wired up.

  • Course Tracker — one row per course, days-to-complete calculated
  • Dashboard — velocity, projected graduation date, CUs remaining
  • Pace Calculator — target date → required CU/week, updates live
  • Monthly Progress — month-by-month log with notes column
  • Pre-Assessment Tracker — scores, weak competency areas, study focus
View on Gumroad — $9