2

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'm confused... you use a Scrum tool and you wonder why you cannot do non-Scrum things with it. Are you looking to drop Scrum or service a non-Scrum team with the same tool? – nvoigt Feb 6 '18 at 9:50
  • Not related to Scrum. – Alan Larimer Feb 6 '18 at 12:51
  • In Scrum, a task is either done or not-done. While some teams burn down work items on the Sprint Backlog as they’re completed if they’ve been decomposed into tasks or smaller stories, a story is never burned down until it has met the Definition of Done. So you shouldn’t burn down partial story points, which seems like what you’re trying to do. Some systems track “consumed” story points separately, but many people (including me) consider that an anti-pattern. – Todd A. Jacobs Feb 6 '18 at 14:49
2

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.

3

TL;DR

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.

Story Points, ZenHub, and Burndowns

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.