Support /remaining
Problem to solve
In the agile daily standup meeting, if a task is not complete, the relevant question is 'how much time is remaining?'
Time remaining is a key part of burn down and burn up charts. These charts are not terribly useful if the time remaining is not accurate.
Gitlab assumes that time remaining is estimated less time spent, which is not really true. Estimates are estimates, and things happen that change how much time things take. Agile is about simply stating how much time is left-- maybe it went faster than I thought, maybe i ran into an issue. Second to completed work, the time remaining, from the view of the developer, is the best measure of progress. Estimates vs actuals are useful in the sprint retrospective.
Today, if the estimated remaining time is not the same as estimated less spending, we have a very annoying problem. I need to change the estimate( a change which is not tracked), or we need to spend time we really didn't spend. Neither are ideal.
The ideal solution allows the developer to reflect reality with the least effort possible. Generally, that's either:
- A time annotation in the commmit that resolves the issue, or
- A single daily comment stating progress
Gitlab today doesnt support either of these options. Adjusting the time remaining requires two separate comments ( /estimate AND /spend), and neither can be done in the commit message
We propose a new tag, /remaining
. This allows a developer to state exactly what they do in the standup-- how much time is left?
Gitlab should display time remaining for an issue, and use it for burndown charts and burnup charts.
The api should be:
/remaining <time remaining>
Then, if the issue has an estimate, the new estimate should be updated to match the provided remaining time. If the issue does not have an estimate, the remaining time plus time spent becomes the estimate.
This is a much better flow for teams who do not care about actuals vs estimates ( IE, true agile teams). A single statement of time remaining is all that's needed daily.
For teams who are tracking estimates vs actuals, /remaining doesn't capture all the of the necessary information. In these cases, the typical daily annotation would be a /spend combined with a /remaining. This is still better than /estimate and /spend, because the developer doesn't have to do the math to adjust the estimate as needed.
Estimates would ideally be tracked as they change, per #28576 (moved).
/remaining, /spend, and /estimate should be supported via commit messages (see #42540 (moved) ) This is HUGE because otherwise developers have to make another comment to track time, which is annoying.