Estimating in story points vs ideal person days

If you use Scrum or other agile methodology you are probably aware that estimation of requirements should be done in story points. If you have investigated further, you should be aware that story point should be some abstract value that is expressing complexity of feature to be implemented and story point should not equal to ideal person day. Some good reasoning you can find here. Very often, the usual mistake is that projects use story point as ideal person day. We did the same mistake too.

There is one additional interesting consequence if you use story point as ideal person day. It can be important if you are using Scrum as a development methodology. When using Scrum, very important value for you and for your customer is velocity. Velocity is number of story points team is able to implement in fixed period of time. Usually, as project goes, velocity should increase. This does not happen all the time but happens very often.

But if your user story == ideal person day, what may happen is that in reality your velocity will increase but it will not be visible in velocity value. How this can happen.

Let say that you have estimated feature F1 with 5 SPs at the beginning of the project. What is good to notice is that at the beginning of the project you are new in the project and technology. So you have estimated first set of features with SPs (ideal person days). After a two or three sprints you are aware of velocity and roughly you know what you can expect in the future. But as your project goes on, requirements are changing and you have to reestimate changed and estimate new requirements.

But now you have much more knowledge of the project. And here comes interesting situation. You have a new feature F10 you need to estimate. Feature F10 is very similar to feature F1, but because you already have experience with the project you will estimate F10 with 2 SPs. So what we have now is that two features of similar complexity are estimated with different ideal person days. If this situation repeats for set of features, you will estimate them with the less time for development. When you include them into sprint, your velocity will remain the same but in reality you have implemented more features.

If you are good or always bad same way in estimation, your velocity cannot change during project lifecycle because you are changing value of story point. This means, nor you nor your customer are not able to notice improvements in efficiency because velocity is same (or slightly changes) all the time.

If you use first set of features as a reference value for estimating new features, you are not changing value of SP, and if you develop features faster than at the beginning of the project, you will see that in velocity.

So what will be conclusion?
Never estimate in ideal person days. Always use story points as abstract value expressing complexity of feature to be implemented.

Now, when you are estimating user stories with story points and expressing their complexity you are able to calculate and estimate your velocity.

But what should you do if you are in the middle of the project and you are already estimating in the ideal person days. Solution is easy. Stop thinking in ideal person days, select representative set of features with different complexity and use them as reference for future estimation. This way you make transition from ideal person days to user stories immediately and more or less painlessly.