Return to Answer

Your company isn't following standard agile practices.

The developers should be the one estimating, in whatever units you use (hours or Story Points or something else). If you are doing the work, you should be involved in estimating it. In fact, everyone who is required to complete the Story needs to be involved in estimating to make sure that the size is appropriate for the estimated amount of work.

As someone who worked for a contractor, I do understand the need for tracking time. Typically, a Story that is worth more Story Points will take longer to complete due to the various factors. However, there isn't a direct relationship between Story Points and hours. You should look at logging time against a project or activity, not necessarily a particular Story.

In order to fix these problems, you should first work on getting realistic estimates in place and using those estimates, along with historical data from previous Sprints, to plan future Sprints. The next step is to look at the overall process to make sure that the Development Team is able to commit to a reasonable amount of work for a Sprint and that, if the work is completed ahead of schedule, that additional work can be brought in. Finally, your Sprint Retrospectives should be used to talk about these problems and come up with methods to fix them.

Your company isn't following standard agile practices.

The developers should be the one estimating, in whatever units you use (hours or Story Points or something else). If you are doing the work, you should be involved in estimating it. In fact, everyone who is required to complete the Story needs to be involved in estimating to make sure that the size is appropriate for the estimated amount of work.

As someone who worked for a contractor, I do understand the need for tracking time. Typically, a Story that is worth more Story Points will take longer to complete due to the various factors. You should look at logging time against a project or activity, not necessarily a particular Story.

To fix these problems, you should first work on getting realistic estimates in place and using those estimates, along with historical data from previous Sprints, to plan future Sprints. The next step is to look at the overall process to make sure that the Development Team is able to commit to a reasonable amount of work for a Sprint and that, if the work is completed ahead of schedule, that additional work can be brought in. Finally, your Sprint Retrospectives should be used to talk about these problems and come up with methods to fix them.

Your company isn't following standard agile practices.

Ideally, you shouldn't be estimating in hours. You should consider estimating in Story Points, which is a measure of how complex the work is. You can then plan your Sprints based on these Story Points and the Velocity (number of completed Story Points) from a few of your most recent previous Sprints. If you happen to finish the work you started, you should be working on the next thing.

The next part is mandatory: the Development Team should be the one estimating, in whatever units you use (hours or Story Points or something else). If you are the one doing the work, you should be involved in estimating it. In fact, everyone who is required to complete the Story needs to be involved in estimating to make sure that the size is appropriate for the estimated amount of work.

As someone who works for a contractor, I do understand the need for tracking time. However, as I mentioned above, you typically estimate in Story Points rather than hours. Typically, a Story that is worth more Story Points will take longer to complete due to the various factors. However, there isn't a direct relationship between Story Points and hours. You should look at logging time against a project or activity, not necessarily a particular Story.

In order to fix these problems, you should first work on getting realistic estimates in place and using those estimates, along with historical data from previous Sprints, to plan future Sprints. The next step is to look at the overall process to make sure that the Development Team is able to commit to a reasonable amount of work for a Sprint and that, if the work is completed ahead of schedule, that additional work can be brought in. Finally, your Sprint Retrospectives should be used to talk about these problems and come up with methods to fix them.

Your company isn't following standard agile practices.

The developers should be the one estimating, in whatever units you use (hours or Story Points or something else). If you are doing the work, you should be involved in estimating it. In fact, everyone who is required to complete the Story needs to be involved in estimating to make sure that the size is appropriate for the estimated amount of work.

As someone who worked for a contractor, I do understand the need for tracking time. Typically, a Story that is worth more Story Points will take longer to complete due to the various factors. However, there isn't a direct relationship between Story Points and hours. You should look at logging time against a project or activity, not necessarily a particular Story.

In order to fix these problems, you should first work on getting realistic estimates in place and using those estimates, along with historical data from previous Sprints, to plan future Sprints. The next step is to look at the overall process to make sure that the Development Team is able to commit to a reasonable amount of work for a Sprint and that, if the work is completed ahead of schedule, that additional work can be brought in. Finally, your Sprint Retrospectives should be used to talk about these problems and come up with methods to fix them.

Your company isn't following standard agile practices.

Ideally, you shouldn't be estimating in hours. You should be estimating in Story Points, which is a measure of how hard the story is. Hardness takes into account effort, complexity, and other factors. You should then plan your Sprints based on these Story Points and the Velocity (number of completed Story Points) from previous Sprints. If you happen to finish the Story assigned to you, you should be working on the next Story. That is, it is possible for a member of the Development Team to work on multiple Stories in the Sprint.

The next part is mandatory: the Development Team should be the one estimating, in whatever units you use (hours or Story Points or something else). If you are the one doing the work, you should be involved in estimating it. In fact, everyone who is required to complete the Story needs to be involved in estimating to make sure that the size is appropriate for the estimated amount of work.

As someone who works for a contractor, I do understand the need for tracking time. However, as I mentioned above, you typically estimate in Story Points rather than hours. Typically, a Story that is worth more Story Points will take longer to complete due to the various factors. However, there isn't a direct relationship between Story Points and hours. You should look at logging time against a project or activity, not necessarily a particular Story.

In order to fix these problems, you should first work on getting realistic estimates in place and using those estimates, along with historical data from previous Sprints, to plan future Sprints. The next step is to look at the overall process to make sure that the Development Team is able to commit to a reasonable amount of work for a Sprint and that, if the work is completed ahead of schedule, that additional work can be brought in. Finally, your Sprint Retrospectives should be used to talk about these problems and come up with methods to fix them.

Your company isn't following standard agile practices.

Ideally, you shouldn't be estimating in hours. You should consider estimating in Story Points, which is a measure of how complex the work is. You can then plan your Sprints based on these Story Points and the Velocity (number of completed Story Points) from a few of your most recent previous Sprints. If you happen to finish the work you started, you should be working on the next thing.

The next part is mandatory: the Development Team should be the one estimating, in whatever units you use (hours or Story Points or something else). If you are the one doing the work, you should be involved in estimating it. In fact, everyone who is required to complete the Story needs to be involved in estimating to make sure that the size is appropriate for the estimated amount of work.

As someone who works for a contractor, I do understand the need for tracking time. However, as I mentioned above, you typically estimate in Story Points rather than hours. Typically, a Story that is worth more Story Points will take longer to complete due to the various factors. However, there isn't a direct relationship between Story Points and hours. You should look at logging time against a project or activity, not necessarily a particular Story.

In order to fix these problems, you should first work on getting realistic estimates in place and using those estimates, along with historical data from previous Sprints, to plan future Sprints. The next step is to look at the overall process to make sure that the Development Team is able to commit to a reasonable amount of work for a Sprint and that, if the work is completed ahead of schedule, that additional work can be brought in. Finally, your Sprint Retrospectives should be used to talk about these problems and come up with methods to fix them.