How to Manage Software Projects
Software projects have one unit of progress that matters: code that has actually shipped. Most process trouble comes from measuring something else instead.
The unit of progress is shipped code
In a lot of project work, progress is a matter of degree: a design is roughly finished, a report is nearly done. Software resists that. A feature either compiles, passes its tests and runs in production, or it doesn't; there is very little useful middle state. That single fact shapes most of what's different about running a software project: the plan has to account for work that looks finished and isn't, and for risk that stays invisible until things are integrated and actually run together.
The other difference is where the uncertainty comes from. In many kinds of project work, the biggest unknowns are about people and scheduling. Software adds a layer on top: the code itself can reveal a problem nobody could have specified in advance: a third-party API that doesn't behave as documented, a library upgrade that breaks something unrelated, a data migration that takes four hours instead of four minutes at real production volume. Managing a software project well means planning for that layer, not pretending it isn't there.
What a software project is actually made of
Six moving parts, and delivery usually stalls at whichever one gets the least attention.
Not a wish list. A sequenced answer to "what do we build next, and why." A backlog nobody has re-ordered in a month is a graveyard, not a plan.
Short, fixed cycles that produce something runnable, so the team finds out whether the direction was right before too much gets built on top of a wrong guess.
The point where a second person reads what changed before it becomes everyone's problem. Slow review is one of the most common places delivery quietly stalls.
Automated tests catch regressions cheaply and repeatedly. Manual QA catches what nobody thought to automate. Skip either and it resurfaces later, usually in production.
Getting code that works on one laptop to run reliably for real users, on a schedule the rest of the business can actually plan around.
Shortcuts taken to hit a date. Written down honestly, it gets paid off on purpose. Left unwritten, it accumulates until it quietly outcompetes new work for the team's time.
Estimating software work is its own problem
Many software teams size work in points rather than hours, and the reason isn't mystique. It's that relative sizing survives being wrong about absolute time better than an hour figure does. If a task turns out to be twice as much work as a similar one last sprint, the point value can stay roughly honest even when nobody could have named the hour count up front.
The harder problem is that estimation risk in software doesn't scale evenly with the size of the change. A small change to a well-understood, well-tested part of the codebase is genuinely low-risk. A small-looking change that touches three services, an external API and a database migration is not small at all, and treating it as small because the diff is short is where sprint commitments quietly come apart. Size the blast radius, not the line count.
Branching and release cadence
Most teams settle on some version of short-lived feature branches merged frequently into a main line, rather than long-running branches that drift apart for weeks and then collide in a painful merge. The general rule holds regardless of which specific branching model you pick: the longer a branch lives before merging, the more expensive integrating it becomes, and the cost grows faster than the branch's age; it isn't linear.
Feature flags are worth adopting even in a small team, because they separate two decisions that otherwise get tangled: merged and visible to users. Code can sit in production, dark, until it's actually ready to turn on, which means releases stop being the nerve-wracking event where a quarter's worth of unmerged work lands all at once, and start being routine.
Signs it's actually working
- Can a branch go from opened to merged without someone chasing a reviewer to make it happen?
- Does a release happen on a predictable schedule, rather than "whenever the last bug gets fixed"?
- Is technical debt written down somewhere specific, not just mentioned in stand-up and forgotten?
- Could someone new to the team find out what's in progress without opening five different tools?
- When a release causes a problem, is the cause understood within a day rather than a week?
A "no" to the last one is the expensive one. It usually means nobody can say with confidence what actually changed between the last good release and this one, which turns every incident into an investigation.
Where a tool can help without becoming the point
Most of the above is process, not software, and it works with whatever tracker a team already has. Where tooling earns its keep is in removing the manual translation between what engineers actually do and what a board says is happening. ShipSprint's boards connect to GitHub directly: opening a branch from a card moves it, and a merged pull request closes it, so the board reflects real branch and merge activity instead of someone remembering to drag a card. Cycle-time and burndown analytics come out of that same data, which gives you a fairer basis for a release date than a person's gut feeling on a Monday.
That's one implementation of the ideas above, not a requirement for them. The backlog discipline, the branch-lifetime rule and the debt ledger all matter regardless of which tracker sits behind them.
Common questions
Not in the scheduling sense. Continuous deployment already decouples "done" from a fixed release date. Most teams that deploy continuously still keep a short planning cycle, though, because it's useful for a different reason: it forces a regular re-look at the backlog rather than letting priorities drift silently for months.
The underlying discipline (scope, sequencing, capacity, honest progress) is the same. What's different is the shape of the risk: software has integration risk that stays hidden until code actually runs together, and a much sharper line between "written" and "working" than most other kinds of project work.
Any shortcut taken deliberately to hit a date, where the team already knows the proper version and chose not to build it yet. That's different from ordinary bad code, which nobody chose on purpose. The distinction matters because deliberate debt belongs on the backlog as a real, sized item, not as a vague guilt that never gets scheduled.
Below three or four engineers, a shared backlog and a habit of small, frequent merges usually covers it. The pressure to formalise shows up once branches start living for more than a few days, or once two people can no longer keep the whole system's state in their heads, and that tends to arrive earlier than teams expect.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required