Günther Gerlach

written by gunther gerlach-2009

There are many approaches for the estimation of a project. Some people will tell you to use the estimation based on story points from Fibonacci numbering system, however this approach only work when features are similar enough to keep a project velocity chart (average project velocity per sprint) in your project but, we all know that this is impossible, some features will need less than a hour of development and other sometimes two days. I am not saying that this methodology is not good, I am just saying that is perfect to get your project velocity chart from the project but if you really want an estimate to get the cost and scope from your project you need the estimate in a period of time, usually days of work.

Moscow Rule; When working with stories from a product backlog especially during release planning, Write all the epic stories ( the main use cases ) and instead of stank ranking them numerically, apply the Must Have, Should Have, Could Have or Wont Have rule to each story . Ask the product manager to write a M S C or W in front of every story. This first pass method help to decide what is really important to measure and what is not.

The best way to do this doesn’t have any difference from the Fibonacci numbering system; you still need to estimates as a team. ‘Planning poker’ is a method where each team member writes their estimate on a card and all team members reveal their estimate at the same time. This is quite fun to do and is a great way to get everyone’s estimate before they are influenced by others. Wild discrepancies in people’s estimates are a great discussion point, a way to identify differences in understanding early on, and a way to understand different people’s perspectives about the implementation. During this estimation, I would recommend to get both, time and points for your estimation, to satisfy your velocity chart and your Capacity Plan as well.

Estimating by Time or story points?

Estimating by Time; the estimation by time is the most traditional method and again, in agile development approach, the best way to do this is as a team. ‘Planning poker’ is a method where each team member writes their estimate on a card and all team members reveal their estimate at the same time.

Estimating by Points; As I mentioned before, start ‘Planning poker’. This is a method where each team member writes their estimate on a card and all team members reveal their estimate at the same time. This is quite fun to do and is a great way to get everyone’s estimate before they are influenced by others. Then, estimate your features in points using the Fibonacci numbering system. The points represent the relative size of each feature. For example, a feature with a 2 is roughly twice the size of a 1, which is very simple. A feature with a 5 is a bit more than twice the size of a 2, and a 21 is much more difficult.

Basically it’s the relatively of this estimating approach that is important, not the number itself. The philosophy is that people can’t really tell you accurately how many days or hours it will take to implement something they know little about, but they can tell you whether they expect it, on average, to be easier or harder than so mething else.

When the whole Product Backlog has been estimated, you now know the ’size’ of your project, but it’s in abstract points rather than in real units of time. How do you convert this into a cost and timescale?

Gunther Gerlach