How does Kunagi calculate hours?
We've been playing with scrum for the first time and use Kunagi to help us in that process. What I know from scrum is you either need to choose if you use "points" or "hours". So in Kunagi we did some estimates in point complexity, create a sprint and it magicly come's up with "x hours left".
How does calculate this? Bet it has something to do with velocity but I cannot get my around it.
Statement from Kunagi Team
Kunagi currently gives you no choice. In the product backlog it uses Story Points for estimating user stories. After you pulled a story into the sprint backlog (whiteboard), it uses hours for the tasks. Every time you create a task it automatically gets assigned 1 hour as remaining work. You should adjust this hours to get a realistic burndown chart for your sprint.
Kunagi does not try to convert between story points and hours, because this would contradict the whole idea. It always depends on who exactly is doing the work. A story with 2 SP could be implemented by a programmer in 5 hours while some other programmer would require 10 hours. Or they could decide to pair program this one which would take 16 hours (8 for each one).
Story estimations are long term for stakeholders, clients and managers to give them some clue, when the product will be ready with given features. Task estimations are finer to give the team better overview how their sprint is going.
Status
Issue is closed.
Comments
Wed, May 2, 2012, 15:50 by Marcel
Thank you for the fast response!
I got the idea's behind the story points (I think). We've completed 3 sprints, but the burndown chart constantly didn't give us an accurate "progress". Think this is because we didn't *fully* understand the whole storypoint thing.
Wed, May 2, 2012, 18:58 by Witek (SM,T)
The burndown chart is not based on the story estimation. It is based on its tasks (the sum of remaining work of all tasks in the sprint).
Thu, May 3, 2012, 09:13 by Marcel
I understand now. What we didn't understand at first was that you should use story points for the whole project estimate. But the burned and remaining fields in a task are in hours.
What we did was estimate a story in points (eg 8). Then we created tasks where the sum of "remaining" was equal to the points assigned to a story. So if you are halfway the story, you burned 4, with 4 remaining. Taking it a step further: we said story points where equal to hours. So 8 story points meant 8 hours of work. Using velocity it could tell us when the project should be done.
This is just the experience of an inexperienced scrum team :-)
Thu, May 3, 2012, 11:48 by artjom (PO,T)
It is tempting to relate Story Points to hours, but I would try to resist.
On another note: Good estimation and burndown results in an initial jump in the graph (the initial creation and estimation of Tasks) and a steady diagonal decrease, similar to the ideal line. Having many vertical jumps is a sign of inaccurate estimation. However, that is perfectly normal for new Teams and from my experience estimation gets more acurate the more Sprints you complete.
Thu, May 3, 2012, 12:40 by Marcel
The crazy jumps in the burndown chart was the reason to post my initial question. The burndown was almost always far away from the ideal line, and we had some troubles bringing it down to earth :-)
Thanks for all the comments!