How to provide estimates as a Junior Developer?
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.
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.
I'm providing a list of key things that are commonly used with the Agile development workflow.
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 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 tough to spot for a new developer and a good lead should explain this and guide you on how to handle scope creep.
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.
This one is relatively 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 your vacation duration is a week or more, you must ensure that you reach out to the team after you come back and find out if something has changed that might impact your coding before your break. Also, it usually takes a day to build context and get back to that 'work mindset' after a 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.
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
Thank you for this post! I find estimation also really hard. Sometimes i estimate too much sometimes to low. I learned that its important that you always estimate based on the task itself and not e.g. the Product Owner or Team Lead. Sometimes you like the person and dont want to let her/him down and estimate to low. Always focus on the task itself.
Thanks for reading and your comment. Like everything in life we constantly learn and evolve. I've had plenty of experiences when I've gone terribly wrong in my estimations. Thankfully, either the client or my lead has been understanding enough to work with me through my transgressions. Thanks once again. Appreciate your comment 😎🙌