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

"Start" command changes task estimate #39

Open
Two9A opened this issue Jul 22, 2013 · 5 comments
Open

"Start" command changes task estimate #39

Two9A opened this issue Jul 22, 2013 · 5 comments

Comments

@Two9A
Copy link

Two9A commented Jul 22, 2013

When using ralio start to mark a task as In-Progress, the estimate and todo fields on the task are changed to "1.0". This is probably incorrect behaviour.

@igorescobar
Copy link
Collaborator

Hello! ;)

Actually, that is an expected behaviour. People usually don't estimate tasks, only user stories and living the to do and estimate empty. That causes an bad collateral effect making the burn down inefficient. That's way ralio behaviour like this. Just to make sure that the burn down is working as expected.

2 similar comments
@igorescobar
Copy link
Collaborator

Hello! ;)

Actually, that is an expected behaviour. People usually don't estimate tasks, only user stories and living the to do and estimate empty. That causes an bad collateral effect making the burn down inefficient. That's way ralio behaviour like this. Just to make sure that the burn down is working as expected.

@igorescobar
Copy link
Collaborator

Hello! ;)

Actually, that is an expected behaviour. People usually don't estimate tasks, only user stories and living the to do and estimate empty. That causes an bad collateral effect making the burn down inefficient. That's way ralio behaviour like this. Just to make sure that the burn down is working as expected.

@Two9A
Copy link
Author

Two9A commented Jul 22, 2013

Interesting. Don't suppose we can add an option to have it not change the estimate? (--keep-time or something...) I ask because we generally put task estimates on story contents, so obviously the burndown's affected by changes to those.

@igorescobar
Copy link
Collaborator

A good "work around" to this problem is verify is this is already set and only set those fields if those are empty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants