3 ms·

The five most effective tips for estimating are in my opinion: - use historical data (keep previous scopes and estimates and read them back in the future) - b

The five most effective tips for estimating are in my opinion: - use historical data (keep previous scopes and estimates and read them back in the future) - break down into chunks - use planning poker: question your assumptions (oh I though the smtp was already available etc) - estimate tasks in relative fashion: compare one to another, in the same project, or compare to previous projects (we're better at comparison than absolute estimate) - use historical data (did I mention it already?) If I can share something: USE HISTORICAL DATA! It just works. As well another tip from Mike Cohn (most of above comes from him): always use ranges when estimating.

jqueryin 15y ago
Funny that you mentioned planning poker. I only recently heard about this strategy and it sounded like a great way to hash out the underlying difficulty of a feature in a group atmosphere. There's also a free site for playing the game. It'd be nice if this somehow tied into my Pivotal Tracker account to actually set the points once agreed upon (and to also pull down the stories that don't have set points). http://www.planningpoker.com/ http://www.planningpoker.com/
- jseban 15y ago
  We do agile and planning poker in my team. The downsides is that all user stories must strictly be phrased from business/end user point of view, and there is no time to do any technical investigation before estimating. How it works is you sit in a meeting, and for the first time hear about a new feature, for example "user wants to click one button to see all historic events grouped by week". The questions that arise are usually along the lines of: * is this data available? we're not sure * is this particular part of the system messy and hard to change? we're not sure * are we really sure this is what the user wants? _all_ historic events? we're not sure And then, you estimate. Which means there is a lot of guessing and either/or going on.. and you churn through a whole bunch of stories in one sitting. Sometimes I wish for a more strict process with more of a technical proposal for changes. Either that, or to get involved with the business side right when they start discussing the new feature, to have a change to look into it/think about it from a technical point of view, while it's getting worked out to a user story.
narcissus 15y ago
When I was at university we did a course on the "Personal Software Process". During the course we had to write / revise / extend a very basic application that tracked this process. Naturally, we had to use the process while developing the application to track the process :) Either way, a couple of years ago I found http://www.processdash.com/ http://www.processdash.com/ which discusses the process and has a download for managing it, too. Anyway, it's a free download and it does just what you mention in your two last points: use historical data and compare like tasks.

jqueryin 15y ago

Funny that you mentioned planning poker. I only recently heard about this strategy and it sounded like a great way to hash out the underlying difficulty of a feature in a group atmosphere. There's also a free site for playing the game. It'd be nice if this somehow tied into my Pivotal Tracker account to actually set the points once agreed upon (and to also pull down the stories that don't have set points). http://www.planningpoker.com/ http://www.planningpoker.com/

jseban 15y ago
We do agile and planning poker in my team. The downsides is that all user stories must strictly be phrased from business/end user point of view, and there is no time to do any technical investigation before estimating. How it works is you sit in a meeting, and for the first time hear about a new feature, for example "user wants to click one button to see all historic events grouped by week". The questions that arise are usually along the lines of: * is this data available? we're not sure * is this particular part of the system messy and hard to change? we're not sure * are we really sure this is what the user wants? _all_ historic events? we're not sure And then, you estimate. Which means there is a lot of guessing and either/or going on.. and you churn through a whole bunch of stories in one sitting. Sometimes I wish for a more strict process with more of a technical proposal for changes. Either that, or to get involved with the business side right when they start discussing the new feature, to have a change to look into it/think about it from a technical point of view, while it's getting worked out to a user story.

narcissus 15y ago

When I was at university we did a course on the "Personal Software Process". During the course we had to write / revise / extend a very basic application that tracked this process. Naturally, we had to use the process while developing the application to track the process :) Either way, a couple of years ago I found http://www.processdash.com/ http://www.processdash.com/ which discusses the process and has a download for managing it, too. Anyway, it's a free download and it does just what you mention in your two last points: use historical data and compare like tasks.