Being a great coder is only part of the skills required to be a professional developer. A professional developer is never isolated with the code. All work is done within the context of a project. A professional developer delivers not only high quality code, but also high quality time estimates.
Back in June I wrote about programmers’ time estimates. With more than 100000 views of that post and a lot of interesting comments I want to take a closer look at a common mentality if developers.
Time estimates are impossible. It’s done when it’s done.
That mentality is totally incompatible with being a professional developer. Let’s look at a software project from the perspective of some of the stake holders and see why accurate time estimates are essential for them. It’s not only a matter of some accountant wanting to know the cost for the project. The time estimates are often a key factor when making decisions on what to do and when. Those are decisions that in the end affect the developers.
As a professional developer I definitely have an interest in getting the estimates right, because if they are wrong some bad decisions are going to be made. I think we all know what bad decisions in a software project means: Developers having to work overtime. I don’t like it. Do you?
The Product Owner
The product owner in a Scrum project is the one creating the prioritized product backlog. The order of the backlog is often described as based on business needs only. When the backlog is showed to the developers, the priority is already fixed.
The problem with that description is that it is completely wrong.
It assumes that priorities can be set based solely on how much the business benefits from each feature. To make an informed investment decision (if a feature is to be implemented or not) both estimates of the benefits and estimates of the costs are required.
To a layman it’s often impossible to figure out how hard a specific feature is to implement. I’ve often been involved in discussions where the product owner is a whole magnitude wrong on their gut feeling of how much time a task will take. When I inform them that a specific feature can be implemented much faster than they anticipated, the cost benefit analysis is completely changed and the feature often become more prioritized. The other way around of course happens too – when they realize how hard a task is, the cost becomes larger than the benefit and the item is removed from the backlog with a note “not worth it”.
To enable the product owner to make an informed decision, a time estimate is needed. That’s why I always give a preliminary estimate when I’ve approved the requirements of an item.
The Resource Owner
The product owner is probably the one most directly affected by the time estimates, but certainly not the only one. Somewhere in an organization there’s always a resource owner. Your resource owner is the one responsible for the budget covering your salary.
My resource owner is my boss. He’s not directly involved in my projects, but there is one thing that is extremely important for him to know: When I will no longer be needed in the project. That’s when he no longer can charge the customer for my time. He must know when that happens, because if he is to meet his budget (including having money to my salary) he must have another project scheduled for me right when the old one stops.
Without time estimates of the tasks in the project, it is of course impossible to tell when it is done and when it is time to start on another project.
The Receiving Organization
When I’m moving on to another assignment, because the coding is done, the project isn’t really finished. For the receiving organization this is when the really tough part of the project begins. It’s time for the business implementation. The operations department must be ready to host the new application. The business must make room in people’s schedules for training on the new system. There might be data migration that that requires huge manual efforts.
The receiving organization must be able to make plans for the business implementation. The plan has to include a schedule. It might even require extra personell to be hired for a period of time. Knowing the delivery time is of course crucial. The only way to know the delivery time is to have accurate time estimates of the tasks in the product backlog.
Beeing Professional
Being a professional developer not only means producing quality code. It means producing quality code on time. As a professional developer you should set equal pride in your time estimates as in your. Always accept accountability for your time estimates, but only if you have the authority to set the estimates in the first place.
Hi Anders,
Very good post!
But I have a doubt, I work with SCRUM, but I have to estimate the work in hours too. How can I merge points estimates and hours estimates. Is there some tip to do that?
Regards,
Vandré
I’ve never understood the use of story points. Hours is an established unit that everyone understand, so we’ve skipped story points and use hours directly. The challenge is to handle the numbers when the developers on the team have different experience and performance. In my current project we use “standard hours” as the unit of estimation and adjust the available time for each developer. E.g. a fast dev’s actual available time might be doubled before being put in the budget.
Another way would be to find a conversion factor. E.g. 4x would give 1 story point equals 4 hours of work.
are you sure a developper? because you talk like someone who has never coded but has to deal with coders and doesn’t understand their world!
I have not only coded a lot, I also have extensive project management experience and have been in charge of a million dollar yearly budget. Thanks to that mixed background I tend to see things from different perspectives, instead of keeping to a strict coding perspective.
What this post tries to say is that as a professional coder you have to understand that you are working in a business context and that the rules are those of a business. It doesn’t matter if you are a rock star developer. If you’re not ready to play according to the business rules you’ll never be a successful business software developer.
That being said, I hate doing planning and estimates. I’d rather spend my time coding.
If you are able to accurately estimate your tasks in hours then you must be writing simple software without any innovative or complex functionality, you are probably writing data entry software. If you are writing software that requires a certain level of end user experience innovation and complexities such as load balancing or interacting with external API’s that you have not worked with before which is common if you are not building a cookie cutter application, that will be hard if not impossible to estimate and will be orders of magnitude off. That is where story points come in handy as a way to mentally compare the difficulty between user stories rather than to incorrectly quantify the difference. Then velocity takes over and can be accurately used to estimate your backlog.
I manage dev teams and that is quite true. But that shouldn’t stop us from trying to estimate for planning purpose and manage risks.
I don’t think anything here in the article suggests that we cannot be wrong with our estimates. The key is probably adjust frequently and quickly which is why IMHO Agile is gaining traction