Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time Spent #2

Closed
ghost opened this issue Feb 27, 2018 · 3 comments
Closed

Time Spent #2

ghost opened this issue Feb 27, 2018 · 3 comments

Comments

@ghost
Copy link

ghost commented Feb 27, 2018

It would be nice to add the abbility to add to each issue a "tag" like the estime for real time spent

timespent X

and be able to show it in a chart and a table. These can be useful to know the real amount of hours spent in each issue and with this is possible to know the real cost.

@jens-markussen
Copy link
Contributor

Time spent vs. remaining is a very interesting topic. There is a fundamental difference between focusing on the time spend and time remaining. I've been studying gitlab lately (with a view to port Yoda to support GitLab as well; it will not necessarily be so difficult BTW). GitLab introduces for issues both > estimate (like Yoda) and > timespend (as you suggest). The idea is that you update the estimate at the same time that you update > timespend, thereby effectively given an idea of the work remaining (estimate - time spend).

However, I'm still not convinced that this is the best way to do Agile PM. Asking people to track time (which is effectively what you do, when you ask to report time spend) is in my view not aligned with the spirit of Agile PM....

This discussion is indeed a very interesting and fundamental one, so I'm certainly open to input :-)

@ghost
Copy link
Author

ghost commented Mar 8, 2018

We are actually using a spreadsheet for this. The idea is just to give some input to the management team to calculate the ROI of each feature and understand which one were good calls and which ones weren't.
I understand is not related to agile pming and make sense not to have it in the tool!

@Joshuaalbert
Copy link

I think this tool would be in line with Agile. From the Agile manifesto:

  • Responding to change over Following a plan

I think responding to change means being able to understand how much effort has gone into something, and seeing if the remaining effort goes down at the same rate. Like, if you spend a day working on something and you log this as time spent, and then you have a meeting and you are blocked and the estimated time remaining stays the same (by raising the estimated time), then you must respond to change. You must figure out why are you having the obstacle, and who to talk to about it. The use of timespent + time remaining is a valuable indicator that enables you to notice this objectively.

@jens-markussen jens-markussen mentioned this issue Aug 28, 2020
Closed
jens-markussen pushed a commit that referenced this issue Aug 16, 2022
* #259 attempt to simplify app authentication

* #259 attempt to simplify app authentication #2

* #259 attempt #3

* #259 back to start

* Fixes #260

* #259 initial try

* #259 update

* #259 debug

* #259 fix

* #259 debug

* #259 fix

* #259 debug

* #259 debug

* #259 fix

* #259 fix

* #259 fix

* #259 fix

* #259 fix

* #259 fix

* #259 attempt at fix

* #259 attempt at fix

* #259 attempt at fix

* #259

* #259 refined alg for finding owner from search term

* #259 fix

* #259 #260

* #260

* #259 #260

* #261

* #261

* #259 keeping things clean. Concerns raised in #261 will be done separately. Have reverted (commented out) working code using ThrottledPromise instaed of Promise
jens-markussen added a commit that referenced this issue Jun 12, 2023
jens-markussen added a commit that referenced this issue Jun 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants