There are so many tutorials on how to build stuff, but much less on how to actually manage what you're building.
I find a lightweight project tracker super helpful for kickstarting my ideas, keeping me aligned with my goals, and keeping me laser-focused during development.
So, here's what's been working for me over the past five years.
Step 1: Product Requirements
I kick things off with a simple spec sheet with the following:
- Goal: What's the project's main goal or purpose? Why is it important to undertake this project? Understanding the underlying motivation helps me shape the project's scope
- Requirements: what are the critical features to consider the first version complete?
- Phases: what is the essential work for each iteration? I try to keep the first as ridiculously small as possible to build momentum quickly
- Mockup: what does this look like? The goal is to get an idea of what the project should look like. On bigger projects it can also help guide the backend work (e.g. what type of data do we need, format, etc.)
Step 2: Architectural Documents
Once I know what needs to be built, I'll quickly outline what kind of architecture and technologies I'll use to satisfy those product requirements. Part of that is also looking at non-functional requirements such as usability, availability, security, etc. and answering the following:
What is critical? What can wait? What's the bare minimum? What parts can I re-use from another system or app?
I know most engineers are allergic to anything with the word "document", but I've seen time and time again, that just taking a few minutes to describe why I was using x kept me from choosing the wrong tools for the job.
It also does two things:
- It helps me surface the pieces I need to bake into the project right away
- It communicates with my team and/or my future self why these decisions were made so I can learn from my wrong assumptions
By the wayNot all projects need a fully in-depth analysis. A throwaway weekend project? I'll just write N/A everywhere and call it a day. The important part is taking the time to just ask the questions.
Step 3: Feature breakdown & Estimates
Ah, the art of breaking down a feature! I don't believe there's a magic bullet here. I've worked on projects with nothing broken down to ones with a gazillion tasks for the simplest thing. Both have yielded successes and failures, all have resulted in more than a few pissed off engineers.
Here are a few simple principles I have seen work more often than not:
- Think through each high level step that might be required: fights the brain's tendency to underestimate effort required
- Tackle the riskiest parts first (e.g. integrating components, core logic, weak assumptions, etc.): failing early is a great thing
- Iterate relentlessly by removing/editing/consolidating tasks based on progress: the process should adapt to the work, not the other way around
This is what I do:
For each task, I'll write down how long I think it'll take and how risky the task is (I'm a fan of using small/medium/large to guestimate). I'll add everything up and multiply that by a factor of 2 or 3 and that'll be my worst estimate. I like presenting a best case and worst case for each project. I find that creates more grounded expectations than giving one date.
Having worked with agile points before, I reluctantly think the overhead is not worth the benefit, at least in my experience.
I say reluctantly because there are parts I really liked. For example, estimating as a group surfaced a lot of false assumptions and pitfalls. But I'd be lying if I said it was easy to wrap my head around how the work mapped to points (Fibonacci??), and communicating that to stakeholders was even worse ("We can get 25 points done in one sprint! But I'm not sure how long that'll take...").
Estimating software delivery is extremely hard, and lots of people waayyyy smarter than me have concluded it wasn't really possible at scale.
I've delivered my fair share of late projects. I've also gotten much better at estimating my work by following the principles I outlined.
Step 4: Scheduling
Equipped with an estimate in hours and days, my next step is to simply add it to a schedule.
I find this is important because it makes the deadline real in my head. It also keeps me regularly checking mentally if a task fits within the given timeframe.
I keep this page open throughout my development.
Now we know what we're building, how we're building it initially, and how long it's going to take.
Next, we need to visualize the work.
Step 5: Visualizing work
I like using a Kanban style board (Trello has been my go to for its simplicity) that has the following:
- Backlog: tasks that pop into my head while working
- To Do: tasks I outlined in Step 3 or pull from the backlog based on priority
- Doing: what I'm currently working on
- Done: what's done (useful for review at the end of project or communicating with stakeholders)
Here's my productivity secret sauce, on every task I note the following:
- Estimated time for the task
- Actual time it took for the task (fill in step 6)
- Ahead or Behind schedule (fill in step 6)
Step 6: Tracking the work
Right before I start working, I start my timer and place it in a separate screen so it's always in the corner of my eye.
Seeing the time pass helps my mind remember that time is a precious resource, even if it may feel like there's plenty of it.
Once the task is done, and this part is super important as well, I'll update the task's actual time on the board and set its tag to 'Ahead' or 'Behind'.
Updating tasks as I complete them gives me instant feedback on how much time is left for the project.
This is super useful because it shortens the feedback loop of knowing if the project is late or ahead of time.
That type of awareness ultimately guides future tasks: can I afford to go deeper in this area? should I leave this task for the next phase? etc.
Step 7: Retrospective
Once the feature is complete, I'll update the schedule with the real time it took for the project to be completed.
In keeping with the spirit of agile, this is where a mini retrospective takes place: what went well, what could be improved for the next feature, what were the biggest time sinks, etc.
Were all those steps really necessary?
Well no, nothing is really necessary. But I don't know about you, I would much rather take the time up front to plan a bit than work late nights praying the project will be done on time.