Introduction
I recently interacted with a friend who had just started out as a developer and she told me that she found it really hard to provide estimates against the user stories assigned to her.
We had an interesting conversation following that and I thought this might actually be applicable not just to her, but, a much wider audience who might be going through the same thing.
In this article, I will provide my thoughts on how you can go about providing estimates when you start out as a new (junior) developer.
Please do note that the article is in NO way "the only" way to provide estimates and it may largely vary based on the project. This is merely some things to consider that can help you provide estimates and manage insecurities that arise while providing them as a new developer.
Estimation
One of the first things to understand whether you are a junior or a senior developer is that the word 'Estimation' means it's a 'ballpark', i.e., it is not supposed to be exact. Providing the amount of time to complete a task largely varies based on a number of factors such as your current skill level, your overall experience in the field to understand requirements, whether you are building something ground up vs adding functionality to an existing product, etc.
For example, let's assume you have joined a project which has a fairly large codebase. When you are asked to estimate for a feature, your first instinct would be to provide estimates for the time it takes to complete building out the feature. However, what is often 'untold' is the fact, you'll also need to include time in your estimates to perform 'impact analysis', i.e., performing analysis to ensure that the code you add does not impact any other existing functionality. Ensuring that you consider providing estimates for things that are untold requires some amount of experience and hence it is always recommended to have a senior review your estimates before providing them to the lead or manager.
Key Terminologies
I'm providing a list of key things that are commonly used with the Agile development workflow.
User Story
In an Agile process, a feature would be written in terms of a user story, i.e., what the feature means to the end-user. Generally, user stories will be worded like 'As a user, I should be able to do this, to meet a particular outcome'. A good user story should have the acceptance criteria clearly specified that should help you and others identify what are the things that need to be verified to mark the user story completed.
Every user story is sized based on the complexity level and 'T-Shirt' sizing is a common methodology followed in the industry. Every user story is marked with a sizing such as XS, S, M, L, XL based on the level of complexity. The sizing will most likely be provided by the senior members of the team, since, they understand the product and are generally more experienced with the software. As a junior developer, you will be required to break down the user story into smaller tasks and estimate them.
Scope
Scope can simply be explained as the agreed set of things that need to be developed as a part of the user story. Usually, during the development process, things might arise which have not been explicitly stated in the user story and it is important to call them out and notify your senior in the team.
Most likely that might get added to the current story or if the impact is much larger, a new story might get created to address that. However, the important thing to note is that, if you have to develop that as a part of the same user story, your initial estimates will get impacted.
This is something very hard to spot for a new developer and a good lead should explain this and guide you on how to handle scope creep.
Velocity
The term 'Velocity' is used to measure how fast a developer can complete the user story assigned to them. The same user story might take 4 hours for a senior developer to complete, but can take up to, 2 days for a junior developer to complete.
You must understand that it is completely 'normal' and you must feel free to communicate with your seniors about how you feel and ask them for any specific directions/guidelines they recommend for providing estimates.
Imposter Syndrome is a big thing to tackle at this point and your ego might also take a hit sometimes. Acknowledge that and keep telling yourself that this is a learning phase and it's just a matter of time before you will have command over the product and technology.
Capacity
This one is fairly simple. Capacity planning is done before the beginning of the sprint to find out if the developers are on any planned vacation. You may ask, how does this change the estimates? While in most cases it does not. However, if you are going a break of a week or more, you must ensure that you reach out to the team and find out if something has changed that might impact your coding before your break. Also, it takes usually takes a day to build context and get back to that 'work mindset' after a super relaxing holiday 🙂
General Guidelines for Estimation
I would recommend the following steps for providing estimates when you are starting out as a new developer:
- Break down the task into the most fundamental thing. For example, building the Home page of the application can be broken up into building individual components on the homepage.
- Spend some time to understand if there are any more questions to clarify the requirement or things to be called out at this stage that will impact the estimation.
- Think through the corner cases (not just the happy path ones) and find out if they'll impact your estimates in any way.
- Add estimates in hours against each task.
- Your estimates must include time to write unit tests.
- Review your estimates with a senior developer and take notes of the feedback provided by the senior developer.
Even after this, it might be possible, you might take additional time to complete the task and that is perfectly normal. But, it is important to record how much more additional time you've spent as compared to the original estimates. This is 'super important' because, it's a big learning for yourself and your team on where your current skill/understanding level is, and in due time this number will improve as you gain more expertise in the project.
Conclusion
While it can be daunting and stressful as a junior developer while providing estimates in the beginning, remember in due time you'll gain expertise and knowledge about the project and your estimation will start to get much better.
A good project manager or a lead would constantly gather statistics regarding your estimates and provide you with constant feedback on how to improve them. As your productivity improves, they'll be aware of that and keep sending more work your way.
I sincerely hope this article helped you with some knowledge of providing software estimates as a developer who is just starting out in the industry.
Don't forget to subscribe to my newsletter and connect with me on Twitter @skaytech
You may also like the following articles:
- Hiring Software Engineers for Startups - An Engineering Manager's view
- Why do you want to work for us?
- How to evaluate your idea for Product Market Fitment
- What is Value Proposition?
- 5 Must-Read Tips for a Killer Blog Article
- History of ECMAScript and Beyond
- A Practical Guide to help you stay more organized and productive
- What is 'this' in JavaScript?
Top comments (16)
Pro tip: guess, double it, add some more. Then be prepared to be waaaay off still.
If it's a sales person wanting the estimate, triple it. They are going to take some off anyway and put you under pressure
Doubling it has worked really well for our teams. We've been able to meet schedules that way.
It's because people either over estimate their ability, or underestimate the work required. Usually both.
yes it also equals out over many people
but always better to be pessimistic
It's also because even if you know exactly what to do.. you do it in the estimated time, but then the customer asks for 3-4 changes afterwards.. so that doubles the time as well. Also bugs.
Hahahaha.. thanks for sharing 😃
Simplest and best thing to do is not to estimate. Check out the discussion here: dev.to/carmenhchung/how-to-nail-ti...
I tend to agree but usually provide clients with a ballpark range. I explain that the low number is the minimum effort required and the top one is with some nice features like x and x. As for junior devs estimating, I don’t expect them to. I quote the project for how long it would take me and then don’t bill all of the devs hours since they don’t move as fast as I can. As they speed up, I can start increasing their pay for projects.
Thanks for reading my article and sharing your thoughts. Cheers!
If you do not estimate, then how do you learn to estimate?
Your question answers itself - if you don't estimate, you don't need to learn how to.
After a while you will just know instantly for some small known tasks how long they will take. That is not an estimate. For bigger unknown tasks, estimation is futile and purely a waste of time
But sadly, the larger industry doesn't work that way. In an ideal world, I'll agree with you. But, having 16+ yrs experience in various types of firms such as enterprise, product and startup industry, providing estimates is fundamental part of building software. If you say, it's not. Then it's an exception the norm. We'll have to agree to disagree on that.
25 years of experience in similar industries says otherwise, but maybe I just do things differently
Thanks for reading and wish you the best!
In fact, I went through the comment chain in your posts. Most of what I would have wanted to counter is covered there. But still, you commented in this section, means you want more views for your content 😎🙌 and I'm cool with that.
I do estimation in about 30% of my working time (it's just an estimation, too :) ), from trivial 0.5hour tasks to several hundred hours projects (client expects everything to be estimated for capacity and scheduling purposes). Sometimes I can use more precise approaches, N blocks x M hours + some slack, testing, communication, etc, sometimes I have to bluff something because noone has any idea how long the task will take, simply there are too many unknown factors (technical or something else). Sometimes I have to send my estimates to be reviewed by other senior teammates. Usually the outcome is OK, we are in an acceptable limit, but sometimes things don't go well. It happens and we have to handle it somehow.
100% can relate to it. Just like everything else in life, we learn based on our experiences and I've seen senior developers also struggle in areas that they hadn't worked before for providing estimates. Like you said, sometimes it's an educated guess. Sometimes, it's about breaking things down and adding values against it. Thanks for reading ☺️