An estimate has to be numeric - I'm not sure how you'd expect a useful estimate to emerge from other types of field (a select list with options of Penguin, Cat and Wombat for example).
Using remaining estimate as an estimation metric would be terribly useless as well - the most simple explanation would be that you'd be double counting everything, or the logged work would cancel it out - all of your charts and reports would be utterly meaningless. The whole point of the estimate is that you say "we think it'll take X", then report on how close you get to X.
OK. Well, how do I properly deal with the following situation?
We have an issue in a sprint that we estimate to 10 hours. In the sprint 11 hours of work is logged, but the issue is not done, and is moved to the next sprint. We re-estimate the issue and set 5 hours on the "remaining" estimate, but since only "original" estimate is counted, it now looks like the issue is done.
I guess what I'm really after is a method of estimation where it counts "remaining estimate at start of sprint", or something like that... Either that or I'm just misunderstanding this whole concept completely. How do you reccomend that issues that are not done by the end of a sprint but has used up all their estimated hours are handled?
If you go over your original estimate, then you go over it. It's an accurate record of what happened. The issue is not "done" just because you've reached or exceeded the estimate, it's done when you finish it, no matter the amount of work.
I'd recommend simply letting the software record what has happened. As you've exceeded the estimate, you know your estimate wasn't great, but it's still going to tell you what happened, and help you with your numbers and trends.
It's perfectly normal to get estimates wrong, but it's worth keeping an eye on the patterns - consistent under or overestimation are something you want to capture and try to amend. As an example, just using JIRA like this has shown that I'm reasonably good at estimating JIRA related small and medium tasks, but I consistently under-estimate the larger stories. I'm dreadful at Confluence estimates too, over-estimating almost all of them until there are add-ons involved. We wouldn't have known any of that if we'd been trying to estimate on "remaining estimate"
While this it true, it makes burndown charts useless, since they will go "flat" on the red line once original estimate on an issue reaches zero. Either way JIRA prides itself on being "flexible" and letting teams work the way they prefer. And there is currently no suitable way to work for teams who prefer to keep the original estimate intact, but still want to re-estimate remaining time on an issue if it ends up taking several sprints to complete.
Thanks for signing up for Jira Ops! I’m Matt Ryall, leader for the Jira Ops product team at Atlassian. Since this is a brand new product, we’ll be delivering improvements quickly and sharing updates...
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