Estimates vs Actual Times for every issue in GitHub

[ghost]

Linked to #321

Estimates vs Actual Times for each task/issue on a project so we know if we are getting better at estimating.

@iteles can you please clarify the priority for this sub-issue of the epic? I'm not sure if this one is a p1

[iteles]

Making this a priority-2 only because #373 should be the only top priority, followed by the other issues in #321 in order.

[Jbarget]

also linked to dwyl/labels#73

[ghost]

@iteles can we action the new labelling system across all of our repos?
dwyl/labels#73

[iteles]

@markwilliamfirth I think we need to trial it in a few more places first - the only people who have tried this out yet are diligent at updating labels and my real question there is whether this will be done across the board.

Happy to add it to hq until we have time ready for use though.

[ghost]

my real question there is whether this will be done across the board

@iteles this is more of a policy and enforcement of policy issue rather than an issue with the system

I don't think this should be put on hq first, I think this should be trialed on a development repo first, as ops issues are very different when compared to dev issues and the main value proposition of this process is towards improving estimations that contribute to sprint planning

I would suggest let's do it on the dwylbot repo and if it works then move it onto one client repo to start with

[Jbarget]

@markwilliamfirth @iteles if it is going to be trialled on dwylbot I would recommend setting clear guidelines on how to use the AT labels. Mainly in terms of the feedback here: dwyl/labels#73 (comment) as its something that we would have benefitted from

[iteles]

As we discussed extensively @markwilliamfirth, this is absolutely not a 'development-only' thing.

We time estimate tasks because:

• Without timeboxing, tasks (especially non-development tasks) can easily extend and take up large amounts of time because of distractions, interruptions and a lack of a plan - time boxing helps to focus on the task at hand
• It forces us to think about tasks before we start on them and devise an efficient plan for how it is done
• This creates a clear set of steps that ensures this process is much more repeatable and saves time for future dwyler
• Actively thinking about the appropriate time boxing for a task and then comparing the actual time taken to the estimate is the best way to get better at estimating and set the correct expectations with those who work with you

Adding this to the hq repo will allow us to better understand how, why and when this works/doesn't work.

As we also discussed, I also agree with this being added to dwylbot as a great next trial.

[ghost]

@iteles again would voice my disagreement with the initial repo being hq vs a dev repo, can explain my reasoning fully here if you'd like

[iteles]

I did not suggest that the initial repo be hq. The initial repo has already been tudo. The suggestion now is to roll it out to dwylbot & dwyl-site as you suggested and hq in parallel.