When should I use the time tracking system (/estimate, /spend) and when should I use the issue weight?
I think the burn down chart only takes the weight into account. Is there a burn down chart taking the estimates into account or something similar?
1 Like
Interesting question. I use the weights to indicate importance. I have not tried to get my team to use the time tracking feature but I’m interested to hear how others are using this.
We are considering moving from Jira to GitLab for issue and project management.
How to use weight and time tracking have come up. Is there a best practice by GitLab?
From what I’ve seen burndown/up charts etc can use weights but not estimated/spent time.
I’m contemplating whether we should set weight to match time, i.e. if time estimated is 8h then we set weight to 8 as well. Setting weight to importance for example would not make sense for burndown/up charts etc.
I found that I like using “weight” as an indicator of criticality. In other words “how important is this?”. I think this can help direct effort because the product manager can identify the criticality of various items and the developers/engineers can identify the labor/time. Once you have both pieces of information, it will be obvious where to direct resources (to items with high weight:time ratio). Likewise, the burndown chart will be an indicator how much value is being added over time and/or how close you are to being ready to make a release.
As an example, you could have each of the following:
1 A simple bug that completely breaks your product for some users (high criticality, low time)
2a A new feature that many users are clamoring for (high criticality, high time)
2b A simple simple that is a minor nuisance for some users (low criticality, low time)
3 A complex issue that is a minor nuisance for some users (low criticality, high time)
You obviously want to focus your developers on those issues roughly in the order I have listed them. The burndown chart will drop quickly at first, then slowdown over time. At some point, the remaining items will just be of the #3 variety. That is the point where you may start to think about doing a release and deferring some of those issues to the next sprint cycle.
Interesting input. While your solution handles high criticality (impact?) and time consumption it doesn’t handle the likelihood or have you factored that into criticality?
I would argue that just because an issue has a high severity/criticality/impact doesn’t mean that it has a high priority. If it is very unlikely to happen and/or only happen to a fraction then there might be other issues with lower severity that has higher priority. Or what do you think?
What I’m missing in GitLab is the ability to have customized fields for such thing as priority, severity/impact, affects version/s, fixed in version/s etc. There is an ongoing epic for it, but sadly they’ve come to a conclusion that I don’t agree with.That custom fields with mainly be used for governance and compliance and therefore is a Ultimate Tier feature.
As for the burndown chart if you use “criticality” as weight how do you easily see if you are on schedule timewise? It would have been different if you could have seen the burndown chart in time estimated and spent.
I wasn’t really thinking of it in an LxC sense. But if I wanted to take the approach, then I would just take the product numbers (1-25 numbers in the middle of the chart) and normalize them to a 1-10 scale to use as my “weight”.
However you choose to do it, you are going to have exceptions and “special cases”. The numbers help you sort the data, but ultimately it’s up to the product manager to make decisions about where to spend resources and how to prioritize things. This is a tool and, as with a hammer, just because you are holding one doesn’t mean you need to hit something with it.