We are using ZenHub for Scrum and doing point-based estimations.
When there is a issue to estimate can't we do hour based estimations with GitHub? As I can see, only point-based estimation is available.
Also, is there a way to specify the completed hours/remaining hours there? Because any progress on the burn down chart is not indicated until we close the issue.
I agree with everything Todd said, and want to add a few points:
You note that
Because any progress on the burn down chart is not indicated until we close the issue.
This is by design. The idea behind Scrum is that if you have a Story that you've been working on for 3 days, and it isn't done yet, then that Story is 0% done. The reasoning behind this is that, given that a not-completed Story provides zero (or negative!) business value, by treating them as 0% done, you avoid the Team having many '90% done' Stories in play.
You also note:
We are [...] doing point-based estimations. [...] can't we do hour based estimations with GitHub?
Perhaps I'm misunderstanding something, but if your Teams are estimating in Story Points, then... why are you trying to get a tool to allow estimating in time? What is your reasoning behind wanting to do estimation in time? On the assumption that the answer is 'because we need to forecast when certain features will be complete', then what you can do is take the amount of points estimated and divide it by the average velocity (of the Team). Likewise, if it is for some other reason, first consider if you really need to be tracking time in the first place, or if you can solve your problem another way.
A story point based burndown chart doesn't measure time remaining. It measures work-effort remaining, and you must use additional metrics to forecast your schedule based on current scope.
A story point based burndown chart doesn't measure time, it measures work remaining. I won't belabor the fact that canonically there is no 1:1 mapping of story points to man hours, although some people and frameworks do misuse the metric that way. In fact, ZenHub itself addresses the topic as follows:
That's the basis of story points. They're unitless scales of measurement which are sized in relation to other tasks. Unlike hours, which are based on consistent values, story points are based on arbitrary measurements. Their only purpose is to compare a task in relation to the sizes of your other tasks.
In other words, if you continuously update your estimates and "burn down" work completed, you will be able to tell at any point in time how much work remains. In ZenHub, and with user stories in general, this work is a relative measure of level-of-effort, not time. You will then need to use your timeboxing methodology and historical measures such as velocity to forecast when remaining work for the iteration or release is likely to be completed.
