What do you do if there are unforseen problems that maje the estinate unreachable?
Ex: a task is estinated in 10h , but by the 3rd hour the changes break something in anither part if the app. What do we do niw? We cant continue work on this task without repairing the new bug.
First of all, if the task has been estimated for 10 hours, then the estimate is very rough, and most probably a developer (or any other specialist) doesn’t have a very detailed and clear picture of what needs to be done. Additionally, big tasks deprive you of short checkpoints and you’ll be aware of implementation issues when it’s already too late.
To prevent cases like this we usually decompose the tasks into small sub-tasks that take <= 2 hours. This allows the team to identify most of the back boxes and system dependencies at the planning stage rather than during the implementation. If there are tasks that are not clear, you can always create tasks for research. Research has to be time-boxed and to have clear deliverables not to waste time.
If the issue has already raised, you have no other option to stop the development and estimate how much time is necessary to fix the bug.
I’d also advise you to work in separate feature branches so that without merging the feature branch to develop or master, another part of the application is stable. Thus, you’ll be able to work on each feature/task independently.
Let me know if further explanation is needed.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What do you do if there are unforseen problems that maje the estinate unreachable?
Ex: a task is estinated in 10h , but by the 3rd hour the changes break something in anither part if the app. What do we do niw? We cant continue work on this task without repairing the new bug.
Hello.
First of all, if the task has been estimated for 10 hours, then the estimate is very rough, and most probably a developer (or any other specialist) doesn’t have a very detailed and clear picture of what needs to be done. Additionally, big tasks deprive you of short checkpoints and you’ll be aware of implementation issues when it’s already too late.
To prevent cases like this we usually decompose the tasks into small sub-tasks that take <= 2 hours. This allows the team to identify most of the back boxes and system dependencies at the planning stage rather than during the implementation. If there are tasks that are not clear, you can always create tasks for research. Research has to be time-boxed and to have clear deliverables not to waste time.
If the issue has already raised, you have no other option to stop the development and estimate how much time is necessary to fix the bug.
I’d also advise you to work in separate feature branches so that without merging the feature branch to develop or master, another part of the application is stable. Thus, you’ll be able to work on each feature/task independently.
Let me know if further explanation is needed.