Azure Boards for solo engineers: a lightweight setup that sticks
Most Azure Boards guides assume a five-person scrum team. Here's the stripped-down setup I actually use when it's just me — and recommend to other solo and small-team engineers.
Most Azure Boards documentation is written for teams running formal Scrum ceremonies — sprint planning, retros, capacity tracking, the works. If you're a solo engineer or a team of two, that setup is overhead that gets abandoned within a month. Here's the version that's actually stuck for me, across several solo projects and client engagements.
Skip sprints. Use a single Kanban board.
Sprints are a forecasting tool for teams that need to commit to stakeholders on a cadence. If you're solo, you already know what you're doing this week — you don't need two-week boxes to tell you. Switch the board to Kanban with a simple set of columns:
Backlog → This week → In progress → Review → Done
"This week" is the column that does the real work — it's your commitment to yourself, visible at a glance, capped at a number you can actually finish (I cap mine at 5).
Use work item types as a filter, not a hierarchy
The default Epic → Feature → User Story → Task hierarchy is built for coordinating across teams. Solo, it just adds clicks. I collapse to two types:
- Issue — anything that takes more than a couple of hours: a feature, a bug, a investigation.
- Task — a checklist item inside an Issue, for breaking down anything that spans more than a day.
That's it. If something needs more structure than that, it's probably big enough that it should be its own project.
Write the "why" in the description, every time
The single highest-leverage habit: every work item description starts with one sentence on why this matters, not just what it is. "Add caching to the search endpoint" tells future-you nothing. "Add caching to the search endpoint — P95 latency is 1.8s and user research says >1s causes drop-off" tells future-you exactly whether this is still worth doing in three months, and how to measure if the fix worked.
Use queries instead of dashboards
Dashboards are built for status reporting to stakeholders. Solo, your "stakeholder" is you, next Monday morning. A saved query — "Issues in 'This week' sorted by priority" — pinned to your start page does the same job with zero setup overhead.
Tag by context, not by project phase
Tags like "quick-win", "needs-research", "blocked-on-external", and "deep-work" are far more useful day-to-day than tags describing where something sits in a roadmap. When you've got 25 minutes between meetings, filtering by "quick-win" tells you exactly what to pick up. Filtering by "Phase 2" doesn't.
Review weekly, not daily
Daily standups are for synchronizing a team. Solo, a fifteen-minute Friday review — move what's done, re-prioritize "this week," note anything that's been sitting untouched for two weeks and ask why — keeps the board honest without becoming a ritual you resent.
Closing thought
The goal of a board, solo, isn't process compliance — it's reducing the cognitive load of remembering what you're doing and why. Every piece of ceremony you keep should earn its place by making next Monday easier. If it doesn't, cut it.