Proposal : decorelate task burned hours from Remaining
The important thing we want to track fiirst in Scrum is what remains to be done, and remaining is the natural way to do that.
On the other side, having spent x hours on a task does not mean there is x hours less to spend on it : this is only the case if your estimate perfectly reflects what happens, and this is not the most frerquent case.
In that perspective, burned hour could be interesting to track where we made a mistake in estimation and provide a tool to helps improve on that topic during retrospective.
What do you think ?
(By the way, Kunagi is really a good tool, thnaks for it)
Status
Issue is closed.
Comments
Wed, Mar 20, 2013, 13:12 by artjom (PO,T)
I cannot quite understand what you're suggesting. Let me elaborate on the way we implemented estimation and burndown of Tasks in Kunagi. Then, once we see whether we are on the same page here, you could maybe point out what kind of changes you are proposing.
On the Whiteboard, you can estimate planned hours and enter burned hours. Kunagi will automatically decrease the remaining estimation when you enter burned hours, however, you are free to manually adjust that value. Changes in estimation are reflected in the burndown chart on the Dashboard by vertical "jumps" (as opposed to burned hours that appear as diagonal changes between days).
In fact, you can use the "jumpiness" of the burndown chart to deduce inacuracies in the initial estimation.