6 years ago, I started working closely with product development teams, particularly those within tech companies like Spotify, Uber, Netflix, Zapier, and Webflow.
In my conversations with product managers, TPMs, or DevOps, a common challenge began to emerge. I heard things like this over and over:
“ I have a task list, but I can’t see how we got to this point or where we are going. Like what’s our developer’s productivity, are we estimating at the beginning of the sprint correctly, what came up that stalled our ship velocity or even sped it up?”
If you look at how most teams do product development – agile, scrum, waterfall, whatever – they are almost always looking at a kanban board as a snapshot of “now”, but it’s missing all the context leading up to this moment and a roadmap of where things are going. There’s no patterns of how we go to today; there’s no visualization of the mountain they are about to climb.
I think dev tracking apps / project management tools get pretty close: Jira and Linear have built-in mechanics for doing things like this.
But why then did these clients always bring me a spreadsheet or a doc for tracking some of this stuff? And why were they daydreaming of developing “some sort of python / javascript surface” that sat on top of their tracking tool of choice?
At the time, I built a lightweight version of a Burndown solution. It was actually my first published Coda doc when
became a thing, and it had a task table, an automation that would take a snapshot of those tasks to a log table, and a visualization of the story points over time as you burn down the task list to completion. Clients were impressed, some implemented this for their teams.
Then for 5 years, this doc sat in the gallery, got copied a few hundred times, rolled out to countless product development teams. So I thought, now’s a good time to revisit this solution.
In thinking through V2 of the implementation, there are a few improvements that I have made:
: The OG doc had a task list that you’d burn down until the end of the project. This was a common pattern with clients like Uber: spin up a doc, burn down the task list, and close out the doc. And then spinning up a new doc for a new feature development / project. While this is a totally acceptable thins to do, over the years I’ve noticed Coda docs becoming more like ongoing apps that whole departments use perpetually such as Qualtrics PXE (product, UX design, and engineering) roadmap or Tonal’s product team hubs that live on indefinitely. They’ve started introducing pattens for planning and closing out bodies of work where the table lives on forever. There’s now a sprint table that you can group tasks with, including concepts like rolling over tasks to the next sprint if they are not completed.
Evolving Story points: Whether you’re using points or hours to estimate work, an important consideration is how these flow over time. I had originally designed this input to be free-form and static; that’s not how teams actually operate. Usually during planning (upcoming sprint cycle, whole quarter of work), teams will use rough estimates to guess the size of tasks and thus the full stack of work. A common pattern is applying
to the tasks like Small, Medium, Large – this is particularly common with design and marketing teams. Moreover, engineers usually use user story points (or simply story points) when looking through all the user stories (a scoped feature/functionality) from the product requirement documentation. These sometimes go in a Fibonacci sequence: 1, 2, 3, 5, 8, 13, etc and relate loosely to the hours it’ll take to complete a task. I’ve combined T-shirt sizing with these story points for estimating the size of the work. I’ve also added a “Points remaining” data point to capture the reality that as you get in to the work, knowledge of the effort changes and thus impacts the burndown or how long it’s gonna take to finish the body of work.
Burndown charting: I originally had a volume of work overtime looking at the whole task table. This is useful for holistically monitoring things like tech debt on an ongoing basis, but it doesn’t answer the question “how are we tracking on this sprint?” or “when are we going to complete this body of work?” I’ve added a
chart to have insights in to these questions which can be pulled up during the sprint rituals of daily standups, weekly syncs, and close outs/ retros.
Kanban: The first version of the doc was more of a data model. But as teams are actively using the doc as their “app / interface” for work, most teams are using kanban / task boards: grouped by status on the top and then whatever cut on the left like assignee, sprint, team, etc.
