Ten things you should consider when making software development estimations
Client: How long will it take to develop this new functionality?
Team: About 2.5–3 months.
If you wonder why you receive or give a wrong answer to this question, here are ten things that you might not have considered in the estimations:
- The learning curve. It includes three things: understanding the requirement in detail, validating your understanding, and learning more about the subject. A developer is not a business expert and needs to know the business to understand the requirements.
- A developer doesn’t sit on his/her desk and starts coding just like plugging a laptop. Before starting coding, a software developer needs to define what the data structure is, what are the data types, where each field comes, what happens when a user does XYZ action. This step can be called Technical Design, and it is a necessary step.
- Testing. Development doesn’t mean testing in a lot of the situations, but it’s impossible to develop something based on the requirements if you never checked what you produced.
- Documentation. Depending on the project and technology, this could be minutes or days.
- Merges. I think any developer spent a least one day in merging an old branch, which in theory is a maximum of 1-hour work.
- Deployment in multiple environments. A developer code locally most of the time, he/she needs to deploy the deliverables on the development, staging, and production server. Even with automated deployment, this requires some effort.
- Bug fixing. Everyone wants a bug-free solution. There is the expectation that the technical team is fixing the bugs.
- Code refactoring is the natural process of cleaning and simplifying the code of specific functionality. The refactoring process can bring increased performance, faster troubleshooting, shorter maintenance times. It is essential to consider it in the development of multiple features.
- Communication. We need to communicate with our colleagues, our clients, align ourselves as a team on a daily bases. That’s all part of the development process.
- Business Validation. From showing the functionality to the managers / Product Owner to validating that the development meets their requirements, it is part of the validation process.
All the above are part of the actions needed to “develop” a specific functionality. The coding itself is just a step of software development.
What to avoid the misestimation trap? Ask, “ how long will it take to LAUNCH in PRODUCTION a certain functionality?”
That changes the equation.
You might be interested in:
Hamburger Method to Split User Stories from Dev team perspective
The main reason why I use the Hamburger Method to split user stories is to coach the teams to transit from the…
Get your Bloody User Story done
Now, a decade later, I know Agile works, if done the right way. Getting the user stories done is the foundation of the…
How to Write User Stories that Deliver Value to the Customer
Before we discuss user stories, let’s clarify what user stories are?
How to Split User Stories
When it comes to defining user stories, I always give the cake examples to the teams I work it.
How and why the personas must be the starting point of our user stories to build better products
This week I started a new project — CooLab. We need to create an application which helps cooks to reach more people…
User Story Definition Of Done (DOD) in Agile Software Development and the Technical Debt
In Agile Software Development, we use the Definition Of Done for User Stories to ensure the quality of work and to…
12 Alternatives to Product Backlog Refinement meeting
We all hate meetings. For me, we meet to get something out of it. Here 13 workshops that can replace your PBR.