Skip to main content
14 events
when toggle format what by license comment
Nov 7, 2013 at 15:24 comment added Stefan Billiet It's kind of hard to explain why you shouldn't do this in the few characters you're allowed to type in here. Estimating is exactly what it name implies: it's vague, it's a ballpark figure and you can't get better at it in any meaningful, cost-effort balanced way. After all, it's called "estimating", not "calculating". I would advise you to read Neil Killick's posts on #NoEstimates: neilkillick.com/2013/01/31/…
Nov 7, 2013 at 5:42 answer added Asim Ghaffar timeline score: -1
Oct 1, 2013 at 16:12 comment added AgileMan This process is new for me. In the past we have been burning down the task when it was complete. HOWEVER, I am trying to encourage people to get better at estimating. We can look back on our estimates and compare them to our actual and hopefully learn from it. It may be a fruitless endeavor, but it's something I want the teams to try for awhile.
Oct 1, 2013 at 16:03 history edited AgileMan CC BY-SA 3.0
added 1042 characters in body
Sep 30, 2013 at 18:46 answer added CodeGnome timeline score: 7
Sep 28, 2013 at 12:18 answer added Karl Bielefeldt timeline score: 3
Sep 27, 2013 at 22:32 answer added Steven A. Lowe timeline score: 14
Sep 27, 2013 at 19:47 answer added ptyx timeline score: 2
Sep 27, 2013 at 18:16 history tweeted twitter.com/#!/StackProgrammer/status/383656480370880512
Sep 27, 2013 at 17:10 review First posts
Sep 27, 2013 at 17:18
Sep 27, 2013 at 17:10 comment added Arseni Mourzenko @user814064: Good point. Every time I've seen teams estimating every task, they always got it wrong. Sometimes by a factor of 1/10 and more.
Sep 27, 2013 at 17:08 comment added dcaswell Could you describe what your process is? We never use hours in our Scrum planning, and we never report hours remaining. Tasks are done when they're done.
Sep 27, 2013 at 17:05 answer added Matthew Flynn timeline score: 4
Sep 27, 2013 at 16:52 history asked AgileMan CC BY-SA 3.0