Recording Actual Time

[Jbarget]

What?

As a user
I want to be able to easily see how long a task took compared to what I estimated
so that I can get better at time estimating future tasks

How?

For the Tudo MVP work, @Shouston3, @Cleop and I will create matching labels for the actual time taken to complete a task. We will still add a time estimate (prefixed with PT for predicted) before starting the task however when finished, will will add a label to show how long it actually took us (prefixed with AT for actual).

Why?

This will allow us to see clearly the difference between the two for more effective feedback on our time estimates.

[iteles]

The main dwyl app will allow this to be done automatically, but in the meantime as a short term MVP this is non time-consuming and may encourage people to update their time labels more than the current system. Look forward to reading your thoughts on how this went next week!

[Jbarget]

Having tried to implement the AT (Actual Time) labels here, most of the AT labels were applied retrospectively as we thought to add them once the relevant PRs had been merged, just in case more time was spent responding to comments. But keeping track of when things get merged in can be difficult when the project moves fast.

The main difficulty I found when adding the Actual Time labels is when a task was not done in one go. The idea was to add a label once the issue/task was finished. Questions that arise in my mind are:

• how to keep track of time when more than one person works on an issue over time?
• is this when the issue is submitted for review?
• calculating peer review time?

I think this can still work though if we add AT labels as we go along. So if one person works 2 hours on an issue, when they break for the end of the day or they have a blocker, they add an AT2h label. And if someone was to pick up the work the day after, for another 2 hours when they finish, they would remove AT2h and add AT4h

@Shouston3 @Cleop any thoughts?

[samhstn]

I think I prefer this new labelling system.

[iteles]

@Shouston3 Could you expand on why please? 😊

[samhstn]

I think mainly clarity on what the current time estimate label means. What does it mean when a developer updates this time estimate while it's in progress.

I also think it's important to capture both and be more aware of both. The current system doesn't facilitate easily being able to view how your time estimates compare to your actual time taken whereas this new system would do so and make developer give better time estimates.

[iteles]

@Cleop Let us know your thoughts.

Depending on your feedback, we might want to trial this on a couple more internal projects and a client project with one of our less difficult clients first so that we can perfect the system before rolling it out further.

[Cleop]

I like the new system. I think it's useful for the team to get better at estimating. I think it could help the client understand where time has gone if things have changed. Although I think we'd have to be careful about dealing when estimates and actuals vary significantly but if done right, this could make our processes stronger if the developer writes on the issue why things might have taken longer than anticipated. I don't mean this in a naughty school child apologising kind of way but more a we encountered this unexpected thing which meant things were more complicated kind of way.

I also think we'd need to be particularly clear with clients on when new issues should be created for feedback/amends so that the actual times don't incorporate things that weren't in the original spec of the issue. I think this could be a problem in some cases where issues 'evolve' over time but estimates are asked for before this has happened fully.

[nelsonic]

This needs to be automatic and effortless.

[Cleop]

Do you think we could automate this process @nelsonic using the in-progress durations?

[nelsonic]

@Cleop we can automate most of the workflow. 😉
The first step is to clearly define the workflow (better than we currently have) ...
https://github.com/tcm-labs/workflow/issues/9#issuecomment-337686380

[Cleop]

Closing this issue as I don't think the label version is the best way to solve this issue. As @nelsonic said, I think automation is the answer.

[nelsonic]

@Cleop agreed. frictionless automation is essential for this. labels were always (click-heavy) stop-gap.