Hi! I raised this issue on the Handbook repo some days ago, and as I’m planning to work on Newcomer-raised issues on BB.242, I think it’s necessary to start discussing this problem early, mainly because it deals with management concepts and intentions.
In a sense, the time we log on tasks is the “currency” used around here, but currencies should be protected against double spending, i.e. no one should be able to spend the same token/bill twice.
Bringing in the example I used:
121 meetings and other interactions are sometimes logged on the same ticket.
Let’s say devs A and B have a 1-hour 121 meeting regarding ticket T, which as a time estimate of 8h. Both log their time on ticket T. Now there’s a remaining time of 6h.
And hey, it happened this week:
Discussing scope is vital for any estimation. I also took part and contributed to that discussion. Where do my 20m go?
This is double spending of the budgeted time, and it only makes sense if the sum of all logged time on T is the sum of all time put into T , and not the time we expect T to be completed in .
But that’s only the origin.
The real problem is that we’re using the latter definition on sprint planning, estimation, poker and other processes, all of which go into Crafty, Sprints and directy influence our daily work.
That’s the gist of it. Suggestions are welcome! (and needed! 
)
Just to import the discussion here, excerpts from the raised issue:
Gábor: If I think about this, the end result - regardless a special new kind of ticket or using the existing - one is the same: the customer will be charged at the end of the day for the same amount. It is only our internal representation how we logically separate work.
As we can always ask for extension from epic owners and client owners, it is not a problem (in most cases) to have a 1-2 hours extra for a ticket compared to the original estimation. Again, the end result is the same.
Xavier: Having tickets budgets/estimations being all-inclusive is pretty much a feature here - we do want to include the peripheral work there, and that should be taken into account in the estimates, all the way to the budgets we get from clients and have to be paid for afterward.
I agree but only when seeing the big picture. Because we don’t want to ever go over budget plus the interactions I’ve seen and the reliance on Sprints, Crafty and Jira leave room to think that peripheral work must be minimized to stay within hours.
Taking into account what’s in the Handbook about the importance of logging all work and the comments, some solutions could be:
Clarify on the Handbook that estimates and logged time are not strictly binding: This would make logging more flexible. It’s easy to apply, but I don’t think it helps specificity: What keeps me from going over budget then? If I do, is it right to spend X hours dealing with task side effect, regression or badly-specified requirement? This solution leaves many open doors.
Emphasize on the Handbook that estimates are all-inclusive and that double-spending is taken into account: This would help better understand estimates without being so specific, but from what I’ve seen I’m not sure everyone is on the same page regarding this (one of the reasons for this post). Maybe because I’m still a newcomer?
Define another type of logged time: A more flexible type that’s stated to not have such a direct influence on billing (both to devs and to clients). This allows for easier logging of meetings and unexpected issues. It should also provide better peace of mind because this type of time log won’t affect the budget while keeping managers aware of how much work/effort is being put in, without affecting the business side of things, allowing for better decisions to be taken much earlier. In the end, if management wants to bill all those hours, there will be no problem in doing so; even better, they provide insight on the work done.
However, deciding whether and how these “Type B” hours are billed is a whole other subject. There could be a variable rate per ticket, per client or per developer, there are plenty of alternatives. A conversion rate would be the simplest solution but maybe not the best. This would depend on OpenCraft’s way of looking at work. My take is that I don’t mind spending X amount of hours discussing specifications with a client because that makes the subsequent work easier, more efficient and results in a better feature/product, so I’d just log X as a Type B hour. But that’s just me. By far this is the most complex of the three solutions.
Thank you @gabor and @antoviaque for weighing in on the raised issue! 
The same is the case for your screening review and end-of-trial review.