Predictive modelling of estimation in product development

Software developers don't really like to give estimations! not because of any prejudice or hate working with the company, PM, or team, but because of the nature of product (software) development. They have fear of going wrong!

Our industry (IT/Software) is not like the manufacturing industry in which a series of assembly lines exist and expected output can be measured perfectly like no of items produced/hour.

You never predict uncertainty and exception which is there in the operational process which will be carried by a software system.

For a standard workflow like login with username and password, based on 5-6 scenarios software developer can predict that he/she can do it in X days/hours. Processes which has third party API dependencies, extensive exception scenarios and complex workflow

I used to closely work with the development team and I observed even if we organise sprints with only productive hours (5-6 hours/developer) allocation, sprints slightly get delayed. Because exceptional scenarios of getting on the surface during the development, scenarios not from the requirement point of view, that case transfer to the next sprint but developer realise that it would be needed more research and POC before going to applying logic in code.

What is the solution?

well, nobody is perfect! we can't make an estimation mechanism that leads to giving perfect estimation.

but we try to apply simple statical modelling into development that it could help.

Try to study the below modelling, which I thought could be helpful, of course, has the opportunity of improvement.

If you closely study the predictive modelling as mentioned in the image above. we can't predict the time for bugs resolutions, interruptions like meetings, system failure and many other external stimuli.

Instead of the number of hours calculate the velocity of the developer

What is the velocity of the developer?

Velocity = estimated time/acctual time

For example, Developer A has taken 1 hour to finish log in feature as per the accepted scenario and without bugs, this is the actual time he has taken, let say he has given an estimation of 2 hours, so velocity is:

Estimate time = 2 hours

Actual time = 1 hour

Velocity = 2/1 = 2, it is excellent velocity, almost double. but it is will be exceptional cases.

Good Velocity

Calculate the velocity of each task of the developer. Let say Developer A has work on 5 feature and he has the velocity as under

0.6, 0.5, 0.6, 0.7,0.55

So, the developer has consistent values hence we can say that he is giving a good estimation at least. Based on the figures he/she can improve in estimation, but for that above figures are needed.

Bad Velocity

Let say Developer B has worked on 5 features and he has the velocity as under:

0.3, 0.7,0.4,0.2,1

So, the developer has inconsistent values hence we can say that he is giving a bad estimation at least. So now we have statistics to work upon.

Over the period of time developer and the team realise the estimation and root cause of the bad estimation.

I applied the below process before development in the current product development

1. A user story must have a wireframe, all possible exceptional scenarios, validation and messaging, clear workflow (in - process -out), data flow, acceptance scenario and data dictionary.
2. Take a brainstorming session with UI designers, developers and testers before scheduling the sprint. And this is not a sprint planning session of 4 hours! Encourage them (designer, developer and tester) to read user stories properly and understand in their own way (I know 99% of developers do not like read documentation) and trust me this single only exercise gives a tremendous amount of increase in product quality
3. Encourage them to find gaps in user stories and exceptions.
4. After brainstorming, session doubt must be cleared in designers, developers and testers.
5. In the next session when all doubt cleared ( may not be the scenario as something is missing but it can be manageable later) go for sprint planning
6. Apply any method whether it is planning poker or any, now it has the chance to have a good estimation

I have good results from this method and increases my product quality.

Share your thoughts, share your experience with product development.