Estimates and logging time
KAMI Tasks tracks two different kinds of "how big": story points for sizing, and time for hours planned and spent. You do not have to use both — but everything downstream depends on what you enter here, and half-entered data is worse than none.
Where: on the ticket — story points and original estimate in the fields, Log time for hours You need: access to the project
Points or time — which, when
| You want to answer | Use |
|---|---|
| How much can this team take on next sprint? | Story points, via velocity |
| How long will this specific piece take? | Original estimate in time |
| Where did the team's time actually go? | Logged time, via the Timelog |
| Am I on track today? | Estimate + logged, on My Work |
Points are for planning across the team; hours are for tracking reality. Teams that try to use one for both end up with neither — points inflate into hours, or hours get estimated so loosely they cannot be summed.
Story points
Story points size a ticket relative to other tickets. They feed sprint velocity — how many points your team completes per sprint — which is what makes planning the next sprint more than guesswork.
The value comes from consistency, not accuracy. A team that consistently calls a certain size "3" will have useful velocity within a few sprints, even if another team's 3 is different.
Time estimates and logging
Original estimate is how long the work should take. Together with time logged it gives a ticket — and your My Work page — an estimate / logged / remaining position.
To log time, choose Log time on the ticket, enter the duration in the short format (2h 30m) and a note on what you worked on. Every entry appears in the ticket's Work log and rolls up into the company Timelog.
Log as you go rather than reconstructing on Friday. Small honest entries beat one invented one, and the note is what makes the entry useful later.
Planning dates
Tickets carry a start date and due date. If you know the due date and the estimate, Calculate Start Date works backwards to when work must begin — useful for deadline-driven work.
Due dates are what My Work reads to build its buckets, and what automations can chase. A ticket without a due date can never be overdue — which is either fine or a problem, depending on the ticket.
What Happens Next
- Story points on completed tickets build velocity, visible in Sprint Insights.
- Logged time appears in the ticket's work log, the company Timelog, and the sprint's hours figure.
- Estimate minus logged drives the "remaining" figure on My Work.
- Logged time is visible with your name on it. It is a record, not a private note.
Tips
- Estimate before the sprint, log during it. Estimating retrospectively defeats the purpose; logging retrospectively loses the detail.
- Put an estimate on anything you want tracked. Without one, logged time still records history but nothing can say how much is left.
- Treat estimates as information, not commitments. A ticket at 12h against a 4h estimate is a conversation, not a failure — and the whole reason to track it is to have that conversation early.
- Write the note. "Fixed bug" tells nobody anything in three months; "traced the timezone offset to branch config" tells them everything.
- Do not point-and-estimate everything. Pick one for your team's planning and use the other only where it genuinely helps.
Troubleshooting / FAQ
Q: My Work shows no remaining time. The tickets have no original estimate. Logged time alone cannot produce a remaining figure.
Q: Velocity looks unstable. Check that sprints are being closed, and that pointing is consistent between people. Velocity from two sprints is noise; from six it is useful.
Q: My logged hours seem low compared to a colleague's. Almost always under-logging rather than under-working. See Timelog on why that report is a poor tool for judging people.