What are some of your best tips/recommendations to ensure that you properly plan enough time when developing software?
The biggest issue I've run into is having "known-unknowns". At the start of a new project (either no code developed or revising someone else's code), developers do not know exactly how long it might take to implement a requirement. It could be as early as 2 weeks, potentially 4 weeks, or maybe 6 weeks if things are much more difficult than expected. There have been times even the most pessimistic estimate was not enough.
Once the team is comfortable with the code and understands how everything is connected, they are able to provide more accurate estimates. But the learning curve can be very difficult to plan appropriately for the PM. Saving Changes...
At what point are you trying to lock in a plan? Estimating is a refining process. If you want an accurate estimate, you will likely need multiple approaches (bottom up, top down, parametric, comparative, three point, etc...) and time. The last time someone asked me when the project schedule would be 100% accurate I laughingly, but seriously, answered, "After the project is complete." If it is work your team has not done before, they won't know how to estimate it. I've found that even 3rd party implementation partners who roll out the same software over and over aren't able to provide accurate estimates until they sit down and spend a lot of expensive time understanding your environment/culture/requirements. They can give estimates before the engagement, but that is based on past experience and still needs some evaluation to make sure there are no conflicts that will change the estimates.
Regardless of whether you are using Scrum, or some variation of a predictive, adaptive, or strict waterfall approach, you have to understand the work before you can give a good estimate. In addition to making sure you understand and can apply various estimating techniques, you should also make sure you are good at managing expectations regarding the accuracy of your estimates and at building relationships that allow you to be honest about what can be delivered by when. Saving Changes...
It's difficult to get good estimates on any project. Software development projects are notoriously bad. It's partly because of the "unknowns" that you mentioned, and also because software can be so complex. It's just very difficult to think through everything that needs to be done until you start doing it. This is why so many software organizations have abandoned predictive planning projects in favor of incremental software development. It lets your developers focus on what they can accomplish in short duration iterations and adjust as they learn more.
I would recommend finding a way to use relative estimates, as well. It's very difficult to say exactly how long a certain story/requirement will take to develop, but it's much easier to compare two requirements and decide which one is larger. Don't tie your requirements to a clock or a calendar, just have your team "size" their requirements in relation to one another, and then keep track of how much they can accomplish. After a few iterations, you can start forecasting milestones based on empirical data and improve these estimates with each iteration.
Important: Make sure your team estimates independent of management. Software developers are extremely vulnerable to pressure, and they will tell your stakeholders what they want to hear. If there's a customer or an executive in the room who wants a deliverable in 2 weeks, the team will agree to that deadline even though they know it will take 2 months. Remove the management distractions every time you estimate so they can be honest with themselves. Take it upon yourself to do the math and deliver estimated dates to your stakeholders.
There are a lot of specific techniques to accomplish this if you do some searches.
Wade's "Important" comment is truly important! Management will pressure teams to complete work to the point that the schedule is meaningless. And then the managers complain when the project runs over or the product is buggy.
To this day, I am amazed at tasks that seem small, but are big and others that seem big, but the developer completes them quickly.
...
1 reply by Adrian Carlogea
Jul 26, 2019 2:46 PM
Adrian Carlogea
...
"To this day, I am amazed at tasks that seem small, but are big and others that seem big, but the developer completes them quickly."
That's because non-developers appreciate the complexity of a software development task by analysing the complexity of the functionality that the task would bring. This is wrong.
It is not uncommon for a small requirement to require a very big development effort that would take a long time to complete.
That's why when estimating the time needed to complete a software development task the complexity of the functionality that would be implemented should not be taken into account.
Before a developer is starting to work an o task he should spend some time on analyzing the task from a purely technical point of view and he should make in his mind a plan of what he would do to complete the task.
In my opinion the developer should start working on the task for a while without any estimation. If he finishes in a couple of hours then job done if not then he should make an estimation but as he has already started he would be in the best place to do a good estimation.
The most stupid idea is to present a business requirement to a developer or a team of developers and ask him/them to estimate. The developer should create technical tasks for those requirement and then estimate each of them.
Wade's "Important" comment is truly important! Management will pressure teams to complete work to the point that the schedule is meaningless. And then the managers complain when the project runs over or the product is buggy.
To this day, I am amazed at tasks that seem small, but are big and others that seem big, but the developer completes them quickly.
"To this day, I am amazed at tasks that seem small, but are big and others that seem big, but the developer completes them quickly."
That's because non-developers appreciate the complexity of a software development task by analysing the complexity of the functionality that the task would bring. This is wrong.
It is not uncommon for a small requirement to require a very big development effort that would take a long time to complete.
That's why when estimating the time needed to complete a software development task the complexity of the functionality that would be implemented should not be taken into account.
Before a developer is starting to work an o task he should spend some time on analyzing the task from a purely technical point of view and he should make in his mind a plan of what he would do to complete the task.
In my opinion the developer should start working on the task for a while without any estimation. If he finishes in a couple of hours then job done if not then he should make an estimation but as he has already started he would be in the best place to do a good estimation.
The most stupid idea is to present a business requirement to a developer or a team of developers and ask him/them to estimate. The developer should create technical tasks for those requirement and then estimate each of them. Saving Changes...
Community Champion
