[Closed] Discussion to solve the double spending of budgeted time

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! :zipper_mouth_face:)

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! :slight_smile:

@daniel.francis, this usually happens between the task assignee and the reviewer or a newcomer and the mentor and I would say that this is in the scope of the task (and its budget) because the discussion is related to the task. And in a meeting, all the involved people spend their time. So if A spent 1 hour of their time and B did the same, 2 hours of time has actually been spent even though only 1 hour has passed in the wall clock. This is not any different from A spending 1 hour to prepare and ask their questions on the task and B taking 1 hour to check and respond to those questions asynchronously answering them in one round or multiple rounds. Just because the same is being done in a synchronous meeting, doesn’t change anything here.

So I am not sure why you call this “double spending” because that is definitely not what is happening here.

That said, it is important to keep in mind that 121 meetings/synchronous discussions end up spending time N times (where N is the number of attendees) faster than otherwise and that is why it is a good idea to use them only when necessary.

In some cases, more time than was actually spent in the meeting might be logged on a particular task due to the recommendation here.

Till a few months ago, we used to have a per-cell weekly sprint meeting on every Monday and all the cell members attended that. So if 1 hour was spent for the meeting, N hours will be logged in total by the N cell members who attended that meeting even though not all of them had to spend the whole hour for things relevant to them.

Similarly, there is a task BB-3781, where @adolfo is the assignee and @giovannicimolin is the reviewer. However, I participated in the kickoff meeting that was held for discussing the task and kicking off the work as I had a lot of relevant context on this priority issue and wanted to help in whatever ways I could. And after the meeting, all the 3 of us logged the time spent in the meeting.

An estimate of 8 hours for a 2 story-point task will block 7 hours of time for the assignee and 1 hours of time for the reviewer. So I am not sure why you call this “double spending” because 2 different people are spending their time on something and should get paid for it.

Estimates here are just estimates and we try our best to ensure that those are accurate. The estimate for every task blocks time for the assignee and the reviewer. For tasks estimated at 2-story points or lower and a N hour time estimate, N-1 hours are usually blocked for the assignee and 1 hour is blocked for the reviewer. The reviewer time increases with increase in the task complexity.

In addition to these, we often recommend the core team member reviewers to plan and block more time than allocated by default when reviewing the tasks assigned to newcomers because there is a good chance that the assignee will need a lot more help and hand-holding than a core team member.

However, this doesn’t mean that the amount of time that can be spent on a task and logged is unlimited. No, it isn’t. In most of these cases, the time spent on a task will likely affect some budget and hence there will always be some constraints.

So, as mentioned in the handbook, it is the responsibility of the task assignee to proactively assess if more time than estimated might be needed to complete the task and inform the task reviewer and/or the epic owner before actually exceeding the estimate. This is important because it not only keeps the people responsible for the budget informed, but also allows remedial action, scope changes to fit the budgets etc. to keep things from spiraling out of control.

The budgets and estimates are often set based on what we can charge the clients for. So if we “define” another type of logged time, OpenCraft will have to pay those who logged time but who will pay OpenCraft for it?

Let’s say you work on a task for a client X and have a 121 with the task reviewer for it, Why should the client not pay for the 121 meeting time that is directly relevant to the task at hand? The client can even be internal and that wouldn’t change a thing.

This has always been the case. Estimates are for the time needed to do everything to fully complete a task.

I am sure you would have found answers to a lot of these questions and doubts, if you had discussed this with your mentor @giovannicimolin during a mentoring session, for which some time is blocked every sprint for Giovanni to answer your questions and mentor you and your onboarding budget is used for it. :stuck_out_tongue: The same is the case for your screening review and end-of-trial review.

P.S. it is generally a good idea to create a task for such long-form discussion forum posts where those responding can log time. If you don’t know whether to do that, how to do that, which epic/account to use, please check with your mentor. Otherwise, folks might either have to spend their own unpaid time responding to this discussion or may choose to not participate.


This probably could be emphasized in the handbook. Most of the “estimates” guidance in the handbook is focused on client discoveries and epics which is a bit “high-level” for a newcomer. There is the Improve task estimates, a checklist section in the handbook, but that is addressing problems after the fact, rather than giving advice upfront.


I realized quite long into reading that there wasn’t a ticket for this. Even if it’s not something you want to discuss further, could you please work with your mentor and have one created so I can mark down the time spent?

In answer to your points, yes, tickets should encompass all time on them in the estimate. However I’d agree with you that I have not always seen this be consistent. I wish I could find a recent MatterMost thread where I asked about the time needed to have every person reply to a forum post (like this one) and how I didn’t always see us marking estimates accounting for it.

However on reflection this mostly seems to be on tickets where we’re ‘billing ourselves’ and there’s a bunch of discussion from several people. Client-facing tickets usually have review/deploy time built into the estimates, in my experience.


The estimates that we create during grooming and put on the Jira ticket in the “Estimate” field are just for the assignee to help plan their sprint (am I overcommitting myself?), and don’t really have much other effect. Near the end of the sprint, you should update the estimate to reflect the remaining work and help plan your time for the upcoming sprint. So yeah, it’s definitely not “binding”.

When we do a “discovery” for clients, we sometimes produce estimates which are binding, but those typically get reflected in the epic budget, not set on individual tickets, and for those we have a whole How to do estimates chapter of the handbook, which definitely tries to remind people to include all of these things.


@guruprasad, @Fox, @kahlil, @braden you can log time here https://tasks.opencraft.com/browse/BB-3860
Thank you for your responses. I’ll close this thread and include your suggestions on the MR.

1 Like

Once again, thank you for your contributions. Here is the Merge Request that’s resulting from this discussion.