Skip to main content

Relative estimations

Last post 10:04 am September 2, 2018 by Ching-Pei Li
12 replies
06:34 am August 25, 2018

I have seen the way different organisations use relative estimations techniques.Few used them as actual estimations and plan their capacity,few use story points and function points for capacity planning and productivity.Can you pls advise ideal scenario for agile projects to plan for capacity and calculating productivity.


09:23 am August 25, 2018

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?


10:16 am August 25, 2018

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


11:10 am August 25, 2018

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.


01:40 pm August 25, 2018

Sorry, I may have misunderstood your meaning.

I always use the relative estimation method. 

I will take a recent project as an example.


02:22 pm August 25, 2018

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. 


04:59 pm August 25, 2018

>> 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.


11:21 pm August 25, 2018

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.

 


06:39 am August 27, 2018

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.


07:20 am August 27, 2018

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.

 

 


08:10 am August 27, 2018

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.


08:53 am September 2, 2018

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.


10:04 am September 2, 2018

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.

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.