Two Planning Vocabularies in One Module
A task here can carry story points and a sprint, or estimated hours and a milestone, or all four at once. Only one of those vocabularies reaches the cost figures — so which one you plan in quietly decides whether your plan can be costed.
Software project management has two traditions that grew up in different rooms. One counts hours against dates. The other counts points against sprints and refuses to convert them. A tool that supports both is not being generous; it is deferring a choice to you.
Both, on the same row
A single task in this product can hold a sprint and story points, and a milestone and estimated hours, and start and due dates, and a baseline, and a recurrence rule, and a parent task.
Nothing forces a choice. You can run a task board with points and sprints, or a delivery plan with dates and milestones, and the same record supports either.
The two vocabularies, and what each connects to
Field What reads it
Story points Nothing downstream
Recorded per task. No cost calculation converts them, and the critical path does not use them for duration.
Sprint Board organisation
Groups tasks into a period. Deliberately cleared when a project is cloned, because a period does not repeat.
Estimated hours Comparison with logged time
The unit the cost side speaks. Logged hours multiplied by a rate is how labour cost is produced.
Milestone Grouping and reporting
Carried across a clone, remapped to the new milestone. The practical aggregation level in this module.
Start and due dates Timeline and baseline
What the timeline draws and what a baseline snapshots. Real calendar dates, unlike the critical path.
The first two organise work. The last three connect to money and to time. That asymmetry is the whole of this page.
Story points are a deliberate refusal to convert effort into money. A costing module is a deliberate insistence on doing exactly that. Both are in here.
What that means in practice
A team planning purely in points and sprints will produce a beautifully managed board and a project whose labour cost is computed entirely from time entries, with the plan contributing nothing to it.
That is not wrong — logged time is the better cost input anyway, because it is what happened rather than what was expected. But it means there is no estimate to compare the cost against. Cost variance needs a plan denominated in the same units as the cost, and points are not.
A team planning in estimated hours gets the comparison for free: estimated against logged, per task, in the same unit that produces the money figure.
What each planning style can and cannot answer
| Question | Points and sprints | Hours and milestones |
|---|---|---|
| How much work is in this sprint? | Yes | Partly — configurable by you |
| Is the team going faster than last time? | Yes | Partly — configurable by you |
| What will this cost? | No | Yes |
| Are we over our estimate? | No | Yes |
| When will it finish? | Partly — configurable by you | Yes |
| What did it actually cost? | Yes | Yes |
Built and maintained Configurable by you, not maintained by us Not built
The last row is the same for both, because actual cost comes from logged time and issued material regardless of how you planned. It is the estimate side that differs.
The hybrid that actually works
Use both deliberately rather than accidentally. Points and sprints for the team's internal rhythm, where their whole value is that they are not money. Estimated hours on the same tasks for anything that has to be costed, budgeted or quoted.
It is duplication, and it is honest duplication: the two numbers are answering different questions and are not meant to reconcile. What goes wrong is when a team plans in one vocabulary and is then asked a question in the other, and somebody invents a conversion factor to bridge them.
The conversion factor is the trap
Nothing in this product converts points to hours, and that absence is correct rather than a gap. A points-to-hours ratio is a number that is stable right up until the moment somebody is measured on it, and then it is a target. If you need hours, estimate hours.
What AWRA OpsHub does today
- Sprints and story points per task, alongside milestones, estimated hours, dates and baselines on the same record.
- Sprint membership deliberately cleared when a project is cloned, since a period does not repeat.
- Milestones carried and remapped across a clone, as durable structure.
- Actual labour cost from logged time, regardless of which vocabulary the plan used.
- A critical path computed from task durations rather than from points.
What it does not do
- Any conversion between story points and hours or money — deliberately, and we would not add one.
- Any velocity-based forecast of a completion date.
- Any cost variance against a plan expressed in points.
- Any warning that a project is planned in a vocabulary its cost reports cannot read.
- Capacity planning per sprint against people's availability.
Not ours, by choice
- Supporting both vocabularies on one record is a strength for mixed organisations and a trap for anyone who assumes the plan they made is the plan the cost reports read. Nothing in the interface flags the difference.
- The absence of a points-to-money conversion is a position rather than an omission. Building one would produce a number that looks authoritative and is not.
- Nothing here is Malaysian, Singaporean, Indonesian, Philippine or Vietnamese. Southeast Asia is here because software and outsourced delivery teams are major employers, and those are precisely the teams that plan in points and are billed in hours.
One comparison, and one warning
Neither of these converts anything. They surface the choice rather than resolving it.
Estimated against logged hours, per task and per milestone
The comparison the hours vocabulary is already capable of and nothing currently shows. It is the cost-variance view, it needs no new fields, and it is the reason to put estimated hours on tasks even if you plan in points.
A note where a project is planned in points only
Not a restriction — an observation on the project that no estimate exists in a unit the cost reports can read, so cost variance will be unavailable. It converts a silent gap into a decision somebody made.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product.
Talk to us about project planningFour questions about planning units
Does anything convert points into money?
A good answer sounds like
No.
What it actually means
A yes is a red flag. The conversion factor becomes a target the moment anybody is measured on it.
Which planning field does the cost report read?
A good answer sounds like
A named one.
What it actually means
Ours reads hours. If your team plans in points, your plan is invisible to costing.
Can I compare estimated to logged hours?
A good answer sounds like
Yes, per task.
What it actually means
Ours holds both and does not show the comparison, which is a view rather than a feature.
What happens to a sprint when I copy a project?
A good answer sounds like
It is cleared.
What it actually means
Carrying it puts new work into a period that has already ended — a small thing that reveals whether anybody thought about it.
Our position
Plan in whichever vocabulary your team actually thinks in, and put estimated hours on the tasks as well if anybody will ever ask what the project was supposed to cost. The duplication is honest; a conversion factor between the two is not, and it is the one thing here we would decline to build.
Ask which field the money reads
Every project tool has several planning fields and usually only one of them reaches the cost reports. Knowing which is the difference between a plan and a decoration.
Talk about planning and costingFrequently asked questions
Can I use both on the same task?
Yes, and for a team that plans in points but bills in hours it is the sensible arrangement. Treat them as answering different questions rather than as two views of one number.
Is there a velocity report?
Sprints and story points are recorded, so velocity is derivable from what is stored. What is not built is any forecast of a completion date from it, which is the step where velocity reporting usually starts making promises.
Why not convert points to hours automatically?
Because the ratio is unstable and becomes a target as soon as anybody is measured against it — which is the specific failure story points were invented to avoid. If you need hours, the honest answer is to estimate hours.
