Software Engineering Management & roadmap handling

Estimation and planning for a better roadmap

Photo by Alvaro Reyes on Unsplash

One of the most important and crucial activity I have as a Software Engineering Manager is the alignment with Product Management on the Roadmap activities.

A good, reliable and stable roadmap is a kind of dream for every developer, because it is the guide of the development activities and not properly calibrating it will create big inefficiencies. But roadmaps are created for being continously reviewed and when needed changed. Having a development roadmap defined spanning one year and pretending to be written in the stone and unchangable is impossible. I never observed it happening. There will be several circumstances for which a change is needed from business perspective, so we should not be scared for planning again and changing, at least until it is done in the best way possible and without following any schizofrenic pattern. We assume we have a healthy Product Management, so the requested changes are conscious and well pondered and not wished without a strong reason and vision ahead.

Anyhow everytime a roadmap has to be changed difficult days will start. It is a difficult task because you have on the table the current roadmap with ongoing activities which could be stopped, new activities with potential due dates, effort estimation for the activities, resource allocation problems. All mixed and interlaced. Everything contribute to make the roadmap shaping complex, especially for the several constraints you have to handle in parallel.

In this post I want to reflect only on one ingredient of the entire recipe: the effort estimations. The software engineering world is divided in two pieces: on one side there are who do not care about estimations at all and suggest to totally avoid doing them, while on the other side there are people like me who believe that doing estimations is anyhow important despite how difficult and uncertain it is.

Practical experience tells me:

1. Estimations must be done by the technical persons, even better by the ones who will do the job.
2. Getting an accepting an estimation from outside the technical area is like a bomb! Most of the time it will be under-estimated even one order of magnitude, and it will make failing the roadmap and the spirit of the team.
3. Try to avoid as much as possible punctual estimations. Any number should have an uncertainty associated and we should work considering it. But if we do not have data and power to digest distribution of estimations, at least provide a range [min, max] for your estimations, being yourself high confident to be right.
4. Doing estimation is a learning process, do not be scared to do an estimation even if you are a junior. What’s important is to track your numbers, both the estimation and the effective effort and you will learn. So do estimations and record the data.
5. Estimations must be taken for what they are, i.e. estimations. They are not promises. If the company culture will push in that direction a negative spiral will be triggered. Developers will start overestimating too much for being confortable to deliver on time what was considered a promise, but such huge estimations will be soon not trusted and trashed by people outside the technical area, and the roadmap will be shaped with estimations made by we do not know or even without any estimations. The risk of failing at every level is huge.
6. Estimations will be wrong not only because of the lack of experience, but also because when doing the real job you will discover elements you were not thinking about, or the requirements will be clarified during the activity itself, or technical difficulties will raise unexpectedly, or the people performance will be lower than usual …
7. My personal approach in building up my estimation habits is to apply a bayesian updated after each estimation activity to my prior estimation model. In a next post I’ll show how I did it for several teams, so having for each of them an estimation model that will guide us in understanding better our estimations and so plan more carefully the roadmap.

Let’s go and estimate because it is funny and it forces you to think wider and sometimes out of the box.