Relative estimations

actual estimations

Since it is an estimate, it means that it is a guess. Who can ensure the result of "guessing"?

So what does "actual guess" mean?

Have you worked on function point estimation,cocomo estimation techniques?

The COCOMO calculations are based on your estimates of a project's size in Source Lines of Code (SLOC).

How could you “actual guess” a project’s size in SLOC.

Sorry, I may have misunderstood your meaning.

I always use the relative estimation method. 

I will take a recent project as an example.

In most situations, we cannot fully understand how many lines of code or how many functions are needed when the estimate is required or must be executed. 

We can only make a list of features according to the requirements of customers.

When we decide on a set of features/functions as the scope of the project, we will find a relatively small feature as a reference unit, one point.

Next we use it as a reference point to estimate the points of other features/functions. The sum is the relative development cost of the project.

This last part is the most important. We will ask the development team to make a more granular estimate of that function as a reference point. For example, it takes 5 hours to complete this function. Then we can sketch out the total number of hours.

Keep in mind, estimates are inherently a guess. The larger the scope of the project, the greater the error of estimation. 

>> Can you pls advise ideal scenario for agile projects to plan for capacity and calculating productivity.

Regarding productivity, points and velocity are not a good metric for this.  Imagine the scenario where velocity was increasing 10% every Sprint, yet the Development Team was cutting unit testing and refactoring?   Sooner rather than later quality will be impacted and technical debt would start to rage out of control.  Hopefully this makes the point that one metric should never stand alone, you need to look at the entire picture and multiple metrics.

A better metric for productivity is to measure cycle time.  By improving a team's work flow through techniques such as limiting Work In Progress (WIP), teams may become more productive.

Velocity is useful for a Development Team to plan their upcoming Sprint's capacity, and for a Product Owner to produce a release forecast.  Keep it within the team.

Velocity is useful for a Development Team to plan their upcoming Sprint's capacity, and for a Product Owner to produce a release forecast. 

100% agree!

However, even a mature development team can hardly use the same reference value to estimate the story points in the face of new products or projects. So I usually convert to man-hours when the project budget is valued or quoted.

The velocity is only used for the on going forecast within the team.

Hi Ching,

The basic problem, in my opinion, with converting story points to man-hours is that - as humans, we feel obligated to dedicate X hours (as decided/converted) to that task. And even if a task is done relatively sooner, we keep on rechecking whether it has been really DONE or not - call it apprehension if you like. :)

I usually suggest teams to use one user story as base, and estimate everything else relatively. It gives a far better estimate, and plus there is no need for conversion.

Regards,

Adwait.

I usually suggest teams to use one user story as base, and estimate everything else relatively. It gives a far better estimate, and plus there is no need for conversion.

100% agree!

My example is for a PROJECT, or a new product.

Converted to hours just to quote or plan the initial capacity. 

Different projects, the story points are not exactly the same, the team may encounter different problems, then how to plan for capacity?

Get started with what you have and refine as you go. 

It is difficult for the development team to estimate the time of all work. However, it's relatively easy to estimate a few hours of work.

For a clearer explanation, let me use a quantitative example to explain.

Assuming a total of 50 user stories, the relative estimate has a total of 250 story points.

Suppose the development team has 6 developers, how many story points can be done in a two-week Sprint? 

Suppose we make a detailed estimate of the one-point user story with the help of the development team and the result is 4 hours.

If the Development reserves capacity for unplanned work, each developer's capacity is assumed to be 5 hours a day.

So the available capacity for the development team is 6*5*10 = 300. It's about 75(300/4) story points per Sprint.

Use this as an initial estimate to plan. 

At the same time, I can use this estimate, 250 story points, equivalent to 1000 man-hours, estimating the cost of development. Even for agile development, we need to give the customer a reference quote.

At the same time, I can use this estimate, 250 story points, equivalent to 1000 man-hours, estimating the cost of development. Even for agile development, we need to give the customer a reference quote.

In any case, I would encourage that the original estimates are validated empirically as more data is gathered. For instance, after each Sprint, there should be ever-increasing evidence about how accurate the original forecast was.

In any case, I would encourage that the original estimates are validated empirically as more data is gathered.

Yes.

Get started with what we have and refine as we goal.

The more we know, the more accurate our forecast and the lower the risk.