I found many discussions about tracking and estimation of sprints. Scrum doesn't define how to track tasks at all - it leaves it up to the practitioners. Therefore we have lots of discussion everywhere. Two ways are mostly very common and based on best practices:
1) Use StoryPoints for velocity and release brundown - use time estimated/remaining for the sprint burndown (Ok, this one is a legacy for teams which migrated from waterfall and were micro controlled projects)
2) Use StoryPoints for velocity and release brundown - use tasks, sub-task and/or other issues to track the sprint with a burndown (In this case the trustfull relationship is already established with all partners)
We have more den 15 Scrum-Teams which are working with model 2 - About 5 teams work with model 1.
Model 1 is supported by Greenhopper by setting "Estimation Statistic" by "StoryPoints" and "Time Tracking" by "Remaining Estimate and Time Spent".
But Model 2 is not supported at all, because we dont track time - we count open vs. resolved/closed issues (e.g. tasks & sub-tasks). There is not 'time' at all (only by convention 1 task is equal or less than a 1 day).
The only thing I get is a burndown by storypoints, I want a sprint burndown by tasks. Epic/Version burndowns should remain by storypoints - the velocity should also be based on storypoints.
Any idea how to realize model 2 with greenhopper - and without any hacks using time fields?
Its not at all ideal for your needs, but I think you can get that behavior with a work-around assuming you really are using points during your planning retros, and time estimates within the sprint cycle.
Configure the board to use story points for estimates during sprint planning. When you look at velocity, it will be using points. Same for release burndown.
When you start the sprint, switch boards configuration to use time estimates, and make sure stories all have the "include time from subtasks" box checked.
Depending on when the team estimates the tasks, the board will show "scope creep", but it will reflect an accurate "here forward" depiction of effort left on estimated tasks.
...It's true that there are projects in Jira; but they are merely a way to cut off issues, to tell them apart from other sections of work and to apply rules that are specific to that team (the schemes)....
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG