I appreciated your approach to estimating. The article is clear and gave me a very nice overall idea of the PERL method. However, I was wondering whether you have measured the efficiency of the method in your projects.
I mean, gathering completed project's data and check how accurate the PERL estimation was. Has it worked for a great number of projects? Have you found contexts or types of projects in that PERL was more assertive?
PERT works most effectively on projects where the amount of time is the key criteria used to estimate the deadlines (and not other units, such as Story Points). Here are some examples of the projects where PERT can be a must-have solution: 1. If requirements are not specified in detail. 2. The team is just starting to work on the project. 3. For newly assembled teams. 4. If you are going to use new technologies or solutions.
This method's average efficiency, in our experience, is 75-80%. Note that the pessimistic value should not be close to the most likely or optimistic. In our development practice, we set a bigger 'buffer' between the pessimistic and most-likely scenario than between the most-likely and optimistic ones.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey,
I appreciated your approach to estimating. The article is clear and gave me a very nice overall idea of the PERL method. However, I was wondering whether you have measured the efficiency of the method in your projects.
I mean, gathering completed project's data and check how accurate the PERL estimation was. Has it worked for a great number of projects? Have you found contexts or types of projects in that PERL was more assertive?
Keep the good job! ;)
Thank you for your question, George!
PERT works most effectively on projects where the amount of time is the key criteria used to estimate the deadlines (and not other units, such as Story Points). Here are some examples of the projects where PERT can be a must-have solution: 1. If requirements are not specified in detail. 2. The team is just starting to work on the project. 3. For newly assembled teams. 4. If you are going to use new technologies or solutions.
This method's average efficiency, in our experience, is 75-80%. Note that the pessimistic value should not be close to the most likely or optimistic. In our development practice, we set a bigger 'buffer' between the pessimistic and most-likely scenario than between the most-likely and optimistic ones.