As argued in It’s Time to Rethink Agile: The Albatross Method Is the Advanced PM’s Choice, it is time to rethink Agile. This article focuses on one part of the Albatross method — how it handles work amount estimation and scheduling — because that is where most project management frameworks handle the problem worst.
Most project management frameworks treat estimation and scheduling as one continuous activity. A team gathers, discusses a feature, assigns story points, and commits to a sprint. The estimate and the schedule are decided in the same conversation. This is convenient, but it forces several very different questions into one answer:
- Is this worth doing?
- When will it be done?
- Are we keeping up with the schedule?
- Do we have buffer for internal changes?
These questions belong to different people, at different times, and require different kinds of information. The Albatross method separates them. It uses two distinct estimates — a rough estimate for decision-making, and a detailed estimate for planning — and derives the schedule from the second. The result is a scheduling model that stays honest as reality changes, without the ceremony that Scrum and Kanban require.
Part 1: Estimation
The Rough Estimate
The rough estimate exists for one purpose: to let the product owner decide whether a feature is worth doing, and in what order relative to other features. It is deliberately imprecise, because precision at this stage is false precision — no system design exists yet.
The flow is straightforward:
- The product owner describes the new feature.
- The dev team confirms it or proposes an alternative.
- The product owner and dev team agree on the feature, primarily at the idea level.
- A qualified dev team member — typically a veteran, though anyone with the necessary knowledge qualifies — lists the tasks needed to build the feature.
- Each task receives an optimistic day estimate: the number of days assuming everything goes well.
- Each task estimate is multiplied by a risk factor (≥ 1.0) accounting for unseen complexity.
- All task ranges are summed.
- The sum is multiplied by a second risk factor (≥ 1.0), representing the estimator’s uncertainty about tasks that may have been omitted.
The result is a range of man-days, which gives the product owner both a sense of scale and a sense of risk, expressed in concrete numbers.
Both risk factors are subjective. This is not a weakness — it is a deliberate design choice. The estimator must justify each factor in writing, in the estimate result itself, explaining why the number is reasonable, supported by past experience and confidence in the skill level of the team that will do the work. There is no fixed ratio between optimistic and pessimistic figures. A task with well-understood dependencies might yield a tight range; a task touching unfamiliar code might yield a wide one. The justification, not a formula, is what keeps the estimate accountable.
Example. Suppose a product owner proposes adding two-factor authentication (2FA). A veteran developer lists the tasks: user flow design, TOTP library integration, backup codes, database schema changes, UI screens, and testing. The optimistic estimate totals 9 man-days. Applying per-task risk factors yields a pessimistic total of 14 man-days, giving a range of 9–14. A final system-wide risk factor of 1.2, for tasks not yet identified, applies only to the pessimistic side — because the optimistic side already assumes nothing goes wrong. The range expands to 9–17 man-days. The product owner now has a number to weigh against the feature’s value — and a reason to trust it, because the estimator wrote down why.
The Detailed Estimate
Once the feature has been approved in principle, system design begins. The feature is divided into components. Now precision matters, because the next decision — whether to actually build it — carries real cost.
The detailed estimate follows a different logic:
- A qualified dev team member becomes the estimator — usually the person who drew the system design.
- The estimator comprehends all necessary tasks and writes a list of subtasks for each: detailed design, coding, testing, documentation, and so on.
- Each subtask receives an estimated man-day value.
- Subtask values sum into a task man-day number.
- Task values sum into the total work amount estimate, in man-days.
There is no explicit range in the detailed estimate. This is not optimism; it is a consequence of the system design having removed meaningful uncertainty. The estimator commits to a number: the developer assigned to the task is expected to finish within it. If the number is exceeded, the schedule is adjusted and the skill index reflects it — the estimate is a commitment that is measured, not a wish that is forgotten.
The estimate is made as if the estimator were the only developer on the project. This isolates skill from coordination overhead. If the estimator’s skill level differs significantly from the team average, the whole estimate is multiplied by a skill-level adjusting factor. This factor is derived subjectively, by observing past records and comparing the estimator to the team average — not by drawing from historical statistics. The manager may later ask to change the value.
Example. For a reporting dashboard, the estimator might break the work into components: query layer, aggregation engine, cache, API, and front-end. Each component expands into subtasks — detailed design, coding, testing, documentation — each with a man-day value. The components sum to, say, 40 man-days. If the estimator is significantly stronger than the team average, a factor of 1.3 is applied, yielding 52 man-days as the team-level estimate. The product owner now has a final, well-founded number — and a clear point at which to stop the development before costs run away.
Two Side Effects Worth Noting
The detailed estimate produces two consequences that are not incidental. They are among the method’s most valuable properties.
A formal skill-level index. Because the estimator commits to a number, and because team members must later match that number in practice, the estimate becomes a skill-level baseline. When development begins, each member implicitly asks: Can I match the estimator’s skill level? A stronger member will need fewer man-days; a weaker member will need more. Over time, a relative skill level index can be calculated and used to measure member capability in a relatively objective way.
Crucially, this index is not a static label. It is formally decided during the development process. If a person works too fast, their index reflects that skill in the next schedule. If a person works too slowly, the schedule is adjusted to match their real speed. By the end of development, laggers will have emerged — not as a judgment, but as a consequence of the numbers. Their larger adjusting factors expand their development periods, and the schedule tells the truth.
Proactive tech debt repayment. Because places where tech debt accumulates are known, fixing that debt is also scheduled. When a relevant component is scheduled for change, the debt repayment is folded into its task. When no relevant component is scheduled, the debt constitutes a task of its own. Tech debt is therefore proactively repaid, not deferred indefinitely.
The product owner need not worry about these details. Their concern is whether the resulting work amount stays within the range they approved at the rough estimate stage. Because there is no pressing sprint end, all tasks begin and end at natural time boundaries. No component is forced to stay half-done.
Buffers and Overheads
The detailed estimate contains no range, but buffers still exist. An empirical 5% buffer is applied universally to all tasks. It is not a separate line item; it is melted into every task on the schedule. A further allowance is applied at scheduling time to cover fixed overheads per week — primarily uncontrollable fixed meetings and support interference. This allowance is a judgment call by the manager, based on how much of the week is typically lost to overhead rather than to planned work. These overheads cannot be stretched to fit a 5% allowance, which is why they are handled separately and at the schedule level rather than the task level.
Part 2: Scheduling and Execution
Drawing the Schedule
Once the detailed estimate is complete and the product owner approves development, a schedule is drawn.
- All components are placed in an order that reflects dependencies.
- Every component is assigned to a dev team member, primarily by the manager.
- The critical path is visualized.
- The schedule becomes a Gantt chart.
The Gantt chart is not decoration. It is the primary coordination artifact. Because it is consulted constantly, it must show not only what was planned but how the plan is actually going — which tasks are done, which are ahead, which are behind, and which downstream tasks are affected by an upstream slip.
Below is an illustrative Gantt-style diagram. It shows two features developed in parallel by two subteams, roughly five weeks of work, weekends blanked, and today at Day 14. The faint dashed outlines are the original plan; the solid or outlined bars are the actual status as of today.
What the diagram shows. Two features are developed in parallel by two subteams. Feature A’s critical path has slipped: A3 overran by a day, A4 and A5 are now past their planned ends, and A6 through A8 are affected as a consequence. Feature B is partly ahead — B1 and B2 finished a day early, visibly inside their planned bars — and partly held up: B3 is late, and B4 and B5 are waiting on it. The manager can see all of this without a stand-up, and can act: in this illustration, Leo has been reassigned from B5 to help rescue A5. The schedule is not a plan that was made once; it is a live picture of where the project actually is, and what the dependencies imply for what comes next.
During Development
Execution in Albatross is deliberately quiet.
- Team members autonomously pick tasks assigned to them.
- When a task is finished, the member raises a hand, tells everyone, and pushes the work to a shared branch.
- Other members pull from that branch at their convenience.
- There are no stand-up meetings. All coordination is asynchronous through the Gantt chart and the shared branch.
- There is no need to hire a Scrum master to teach the working style.
- The manager performs code review on submitted workpieces.
Every time a task is done, it is marked done in the schedule. Every member can see whether they are ahead of or behind schedule. The manager monitors the same schedule. When a task lags, the manager proactively asks the assigned member, helps solve the problem, or arranges another member to help. This is feasible precisely because the schedule makes capability and availability visible. The manager can see who is ahead and by how much — and therefore knows who can help, and for how long.
When Reality Intervenes
A schedule that cannot absorb reality is not a schedule; it is a wish. Albatross handles disruption explicitly.
Unplanned work. Bugs and urgent requests are not left unplanned. The team plans the work, inserts it into the schedule, and adjusts the schedule if needed. This is a deliberate departure from frameworks that treat unplanned work as an exception. In Albatross, unplanned work becomes planned work the moment it is known.
Critical path slippage. The manager evaluates whether the slip can be caught up. If not, rescue actions are scheduled: adding or switching a member, building a temporary stub for the stuck component, or modifying the schedule. This is a form of re-planning, but it is bounded — it happens against a visible critical path, not in the dark. The rescue arrow in the diagram above is an example: Leo is moved from a task that can wait to a task that cannot.
Multiple features. The same process repeats for each feature. If features are related, they can be merged into a larger feature. Otherwise, the team can be divided into subteams, each developing one feature with its own schedule — as in the diagram.
Rejection after detailed estimate. If the product owner rejects the detailed estimate after having approved the rough one, development is canceled. The team turns to the next feature. This is the final check that the method is designed to provide — a point at which costs can still be avoided.
Feedback Before Completion
In Waterfall, the customer sees the product at the end. If direction is wrong, the cost of correction is maximal. Albatross builds in a natural correction point that Waterfall lacks.
Whenever a component is something displayable to the product owner — a UI screen, a report, an API the PO can exercise, a working subsystem — the team provides feedback just before the component is finished, not after the whole feature is done. The product owner can then adjust direction while there is still time to act on it.
This is not a formal review gate and it is not a ceremony. It is a consequence of the schedule: components finish at visible, natural boundaries, and each one is an opportunity to confirm or correct course. The developer gets more than one chance to be told “yes, this is right” or “actually, no, here is what we need.” Waterfall offers exactly one such chance, at the very end, when it is too late.
The comparison is worth stating plainly: Waterfall defers feedback; Scrum and Kanban produce feedback continuously but without a schedule to anchor it; Albatross produces feedback at component boundaries that the schedule already makes visible.
Retrospection
Retrospectives exist in practice, but they are a matter of organization management, not a requirement of the Albatross method itself. A common practice is to place an improvement task at the end of development, so that problems which cannot be solved immediately are gathered in one place. Improvements need not wait until the end, however. Members propose solutions and raise complaints during development, and improvements happen continuously. The improvement task is a symbol and a gathering point, not a gate.
A Pipeline Is Not a Schedule
Before comparing Albatross to other frameworks, one distinction needs to be made plain, because it is routinely blurred.
Kanban, in its disciplined form, manages a constrained processing pipeline. It sets WIP limits, measures cycle time, tracks throughput, and pulls new work into a stage only when capacity frees up. These are real and useful properties. They keep a system from overloading. They make the rate of work visible.
But none of them constitute a schedule.
A schedule makes a claim about the future: this item will be finished by this date, in this order, given these dependencies. Kanban, even when well managed, makes no such claim per item. It makes a statistical claim: items of this size take about X days on average, so an item entering today will probably emerge in roughly X days. That is a forecast, not a schedule. It describes the behavior of a pipeline, not the fate of a particular piece of work.
The distinction matters because the two answer different questions:
| Constrained pipeline (Kanban) | Schedule (Albatross) | |
|---|---|---|
| Unit of prediction | Aggregate flow rate | Individual item |
| Claim about the future | “Items like this take ~X days on average” | “This item will finish by date D” |
| Ordering | Emergent from pull | Planned by dependency |
| Dependencies | Invisible | Explicit, critical path visualized |
| When something is done | Unknown until it emerges | Committed at assignment |
| Basis | Statistical regularity | Design and decomposition |
A pipeline can be well managed or poorly managed, but in neither case is it a schedule. It is a throughput model. Calling it “continuous flow” is accurate as a description of the pipeline. Calling it scheduling is a category error.
How Albatross Compares
Pure Scrum and pure Kanban each solve a real problem, but each rests on premises that most software development does not satisfy. Scrum assumes work fits a fixed cadence and that a sprint’s worth of work can be committed in advance; Kanban assumes work items are independent and that throughput matters more than any particular deadline. When those premises hold, the methods work. When they do not — which is the common case in software — the methods strain in ways that show up as half-finished components, invisible dependencies, and dates that cannot be defended. Albatross was built for the common case.
A note on “pure.” In practice, teams adopting Scrum tend to tread their own way rather than following the original Scrum. The same is true of Kanban. What teams actually run is a variant — Scrum with a Kanban board bolted on, Kanban with a product owner and a committed date, or some homegrown hybrid. This is usually taken as evidence that the methods are flexible. It is more accurate to read it as evidence that the pure forms do not survive contact with real software work: teams add dependencies, deadlines, and explicit roles because the frameworks leave them out, and those additions are precisely the parts Albatross builds in from the start.
Scrum. Scrum’s strength is cadence — the rhythm of sprints creates focus, and the clarity of roles offsets the cost of coordination. Its limitation is that the sprint boundary is artificial, and work does not always respect it. A component that needs more than one sprint is either split across boundaries, leaving it half-done, or estimated down to fit, which corrupts the estimate. Dependencies that cross team boundaries are invisible to the sprint. And when a sprint ends with work incomplete, Scrum has no mechanism for carrying the partial state forward — it carries the item forward, but the half-finished work behind it is not rescheduled with the same priority. In practice, it is deprioritized, and often never revisited. This is exactly how tech debt accumulates: not through a decision to incur it, but through the quiet abandonment of work that no longer fits the current sprint. Albatross fixes this by removing the sprint boundary entirely. Tasks begin and end at natural boundaries, no component is forced to be half-done, and the schedule — not the calendar — decides when work is finished.
Kanban. Kanban’s strength is flow management — WIP limits and cycle-time measurement keep a system from overloading and make the rate of work visible. Its limitation is that a flow model is not a schedule. Kanban can tell you how fast work moves through the system on average; it cannot tell you when a specific deliverable will be finished, because it does not model dependencies, sequence, or the critical path. For repetitive, similar-sized work — support tickets, operations, maintenance — that is sufficient. For project work with real dependencies, it is not. Albatross fixes this by scheduling: components are ordered by dependency, the critical path is explicit, and each task is committed to a developer with a date. Kanban describes the pipeline; Albatross draws the map.
Kanban’s undefined roles. Kanban prescribes no roles, which is sometimes presented as freedom. In practice it leaves an essential function undefined: who decides what enters the queue, and in what order? A product owner, service manager, or team lead usually fills the gap — the role exists whether or not the method names it. This is not a deficiency in Kanban so much as a silence, but it is a silence every team must break on its own, and the items most likely to fall into it are the ones with no external advocate — tech debt chief among them. Albatross names the function: the product owner owns intake and priority; the manager owns assignment and the critical path.
Tech debt. In both Scrum and Kanban, tech debt is a backlog item — which in practice means it is deprioritized whenever feature work competes for the same capacity. It is repaid only when someone insists on it, and the insistence rarely wins against a feature deadline. Scrum compounds this by generating fresh debt at every sprint boundary, where half-finished work is quietly set aside. Kanban compounds it differently: because Kanban prescribes no role for intake, no one is assigned to put tech debt into the queue in the first place. Feature requests arrive from the product owner; bugs arrive from users; tech debt has no external source. It enters the backlog only if someone internal takes responsibility for writing it down and defending its priority — and in a method with no named roles, that responsibility is unassigned. Albatross removes all three mechanisms: debt in a component is repaid when that component is scheduled for change, no sprint boundary exists to abandon work at, and the manager owns the schedule into which that debt is placed. Repayment happens as a matter of course rather than as a special request.
Slips are caught early, not prevented. Work is uncertain, and tasks sometimes run long. The difference is what happens next. In Albatross, a slip is visible the moment it occurs: the task’s bar extends past its planned end on the chart, and every downstream task that depends on it is marked at risk. The manager sees this early — not at the end of a sprint, not after a deliverable is missed — and can act early: reassign a developer, split the task, build a stub, or adjust the schedule. A slip that is visible early is a manageable event; a slip that surfaces late is a crisis. Albatross does not make slips rarer. It makes them catchable.
WIP discipline, without a policy to enforce. Albatross shares Kanban’s WIP discipline, though it arrives at it by a different mechanism. Because each task is assigned to a named developer, and a developer holds one task at a time, the number of tasks in progress is capped by the number of developers. The cap is not a configured parameter; it is a structural consequence of the assignment model. No one has to enforce it, because no one can breach it without being visibly over-assigned on the chart. When a task finishes, that developer is immediately available for the next one — so utilization stays high without ever exceeding the cap. The team’s capacity is fully used, and never overclocked. Kanban’s WIP limit is a policy — set, monitored, and enforced by someone. Albatross’s WIP limit is a property of the schedule — it holds because of how work is assigned, not because someone is watching.
Where each belongs. Pure Scrum fits work whose scope is genuinely fixed for a sprint and whose components can be completed within one — prototyping, proofs of concept, small self-contained deliverables. It does not fit most production software development, where components span sprints, dependencies cross team boundaries, and the work’s shape is discovered as it proceeds. Pure Kanban fits work whose items are independent and whose release date can loosely drift — support queues, operations, maintenance. It does not fit project work with dependencies and a committed date, because it does not model dependencies in advance and cannot say when a specific deliverable will land. Albatross is for the work in between: project work with real dependencies and real cost risk — where the product owner needs a defensible number before committing, where components must be ordered, where the critical path matters, and where the work itself refuses to fit a fixed boundary.
At a Glance
| Dimension | Scrum | Kanban | Albatross |
|---|---|---|---|
| Estimation | Story points, relative | Optional, flow-based | Two-tier: rough range, then committed detailed man-days |
| Scheduling | Sprint-bounded — commits to a sprint’s worth of work, not a per-item date | None per item; statistical throughput forecast only | Dependency-ordered Gantt with critical path |
| Time boundaries | Artificial sprint ends | Continuous processing | Natural task boundaries |
| WIP limiting | Implicit in sprint scope | Explicit WIP limits — a policy, set and enforced | Structural — one task per developer, capped by team size, no enforcement needed |
| Risk handling | Velocity variance, sprint buffer | WIP limits as policy; no per-item risk model | Explicit risk factors, 5% task buffer, weekly overheads, early slip visibility |
| Coordination | Daily stand-ups, ceremonies | Board-based, pull-driven | Fully async via shared branch and Gantt |
| Role overhead | Scrum master, product owner, team | No prescribed roles; intake and prioritization undefined in practice | Manager (review, assignment), no dedicated master; product owner owns intake |
| Skill measurement | Implicit in velocity | Implicit in cycle time | Explicit relative skill index |
| Tech debt | Backlog item — deprioritized in practice | Backlog item — deprioritized in practice; intake unassigned | Proactively scheduled into relevant components |
| Unplanned work | Absorbed into sprint or next | Pulled when capacity allows | Planned and inserted into schedule |
| Feedback to product owner | At sprint review | On request, ad hoc | At each displayable component boundary |
| What it answers | “What can we finish this sprint?” | “How fast does work move through us?” | “When will this specific work be done?” |
Conclusion
The Albatross method rests on a simple observation: estimation and scheduling answer different questions, and conflating them produces commitments that no one can keep. By separating a rough estimate for decision-making from a detailed estimate for planning, and by deriving a dependency-ordered, critical-path-aware Gantt schedule from the latter, Albatross gives product owners defensible numbers, gives developers committed targets, and gives managers the visibility to intervene before a slip becomes a crisis.
It would be easy to mistake this for a modest rearrangement of existing practices. Dependencies, critical paths, Gantt charts, man-day estimates, buffers, code review, WIP limits — none of these are new. It contains no new tool inventions.
But a method is not its tools. A method is the combination, and the combination is what determines whether the tools reinforce each other or undermine each other. Scrum and Kanban each assemble a set of practices that work well in the context they were designed for, and poorly outside it. Albatross assembles a different set, for the context most software development actually occupies: work with real dependencies, real cost risk, and a product owner who needs a defensible date before committing.
That is where the method’s claim lies. Not in a new ceremony, not in a new vocabulary, not in a new diagram — but in a correct combination of tools that already exist, arranged so that the estimate supports the schedule, the schedule exposes reality, and the team’s capacity is fully used without being overclocked. When a correct combination produces results the incumbent methods cannot, that is not a rearrangement. It is a revolution — and it is the kind that displaces incumbents, not the kind that merely adds to them.
Albatross requires no stand-ups, no Scrum master, and no sprint boundaries. It requires only that estimates be justified in writing, that work be planned when it becomes known, and that the schedule tell the truth — including the truth that a task behind a late task is not “on schedule” but at risk.
Scrum and Kanban will keep the narrow contexts they were designed for. But for the work they were not designed for — which is most software development — there is now a method that fits. That is what a revolution looks like: not a louder tool, but a better fit.