In my last post, I talked about the importance of tracking Remaining Work Hours instead of Completed Hours and some of the reasons why this can work for your team. Because of the relatively short nature of a Sprint (usually 2-4 weeks), one might think it’s not important to update the Remaining Work hours on their individual tasks, but instead just set the task to ‘in progress’ when work starts on them, and when completed, remove the Remaining Work hours and set to done. Truth be told, many times this would be just fine. It might make the Sprint burn down chart a bit more ‘up and down’, but the work would get done just fine.
I strongly encourage teams I work with to update the Remaining Work hours at least once a day on any active tasks. Some have accused me of attempting to ‘Micro-Manage’ the team by this request. I simply say to them now: “You can micro-manage yourself if you want, this request is for the benefit of the team, not me.” By updating the Remaining work hours daily, the whole team has a better picture of how all tasks are progressing, and it allows the team as a whole to quickly identify possible time line issues and adjust to the ebbs and flows of all development work.
The one big caveat that goes with asking the team to update their Remaining work hours daily, is the time entry mechanism has to be simple, fast, and readily available. If it takes more than 30 seconds to update this metric, it simply will not get done consistently.
Though I understand why Remaining work hour entry time (tool wise) can be a barrier to getting it entered, I believe the majority of the time Remaining Work hours don’t get updated daily has to do more with the thinking necessary to attempt to truthfully estimate what is left at the time of updating. Though that can be challenging, it’s worth the effort to checkpoint yourself each day given the new info (or lack there of) you are exposed to. Also, doing this checkpoint daily will get quicker and quicker as time goes on given the amount of practice you will get doing it.