I just wrapped up a three month project in a new tech stack. From the beginning to the end, I was regularly asked: “Will this be done in time?” I was new to the tech, so it was difficult to estimate. The best I could do was document tasks as they revealed themselves, and then point at the percentage of tasks complete as a measure of progress.

For the first couple months, I added more tasks than I closed. The scope of the project seemed like it would grow unbounded, but then it leveled off. Today, I closed the last task. Amazing, and it wasn’t that hard, because we at least had an agreed-upon task tracker. I just needed to tend it.

Some features I like:

• Using the same system used for tracking bugs. This frees folks to use whatever tracker they prefer. A few colleagues prefer a simple spreadsheet of tasks in descending priority, for example. It also enabled folks to use familiar bug tracking tools, like subscribing to updates, assigning ownership, commenting, etc, to communicate about tasks
• At least trying to present a burndown chart. Such a chart is the most accurate tool I’ve found for estimation; even if we can’t estimate the completion time, we can say the job will be done when the number of tasks drops to zero, and easily follow along on the chart.
• Organizing tasks in a variety of ways, notably, differentiating organization by project from organization by week
• Organizing tasks by blocking relationship. In other words, enabling me to specify this task depends on that task. Identifying branch nodes in this tree as milestones is helpful for maintaining a sense of momentum

Some usage patterns I like:

• Presenting the tracker in a periodic (agile, 4DX) cadence meeting and using it to structure discussion. Avoiding tracker maintenance was helpful for maintaining meeting pace
• Agreeing on one approach to tracking helped focus attention and minimize maintenance cost, though an alternative popped in and out mid-project, and the project launch used a different tracker
• Layering trackers. For example, a team-level tracker prioritizing several projects, each with a project-level tracker prioritizing tasks. A product manager might manage the team-level, and each work-stream might manage the project-level.
• Discussing deadlines in terms of the list of tasks to complete, as opposed to a subjective commitment. Rough estimates help in this context, eg 1 hour, 1 day, 1 week. Summing the rough estimations, and comparing the result to the desired date, are at least rational processes. Given the list of tasks, we can also have an objective discussion about priorities.