This article is not for everyone. If you identify yourself as a faint-hearted developer, you might want to proceed with caution, as this article is about estimations.
You’ll say estimations are a really daunting thing. They’re not.
Ok, maybe for the first few thousand times (actual number may vary), but after that, they get progressively easier and actually helpful. Of course they will terrify you at first, because you must provide an estimate for something you know very little about. That is actually how you improve your estimations: by understanding the task and having a good task approach. Also, estimating is amongst the things that you get better at by actually doing them, like sports, or installing Windows.
If, like myself, you’ve set improving estimations as a goal, you might find this article useful, as I’m going to share all my “tricks” with you. This is actually a plan my teammates and I have built together and which, followed rigorously, led to fewer misunderstandings of tasks, fewer interruptions for the client and, of course, better estimations of the tasks.
So what do you need?
A rigorous approach to tasks
You can treat the following items as a checklist, or just questions you need to ask yourself when you start any given task.
1. Does the task exist in Redmine? (or JIRA, Trello, or insert your favourite issue tracker here)
You can’t just start working on something without letting your teammates and the client know about it. This might sound like an auto-include step for every task approach plan, but I shamefully remember the number of times I have neglected to do this.
2. Does the task need breaking into subtasks?
Having an 80 hours task is unacceptable. It must be broken down into two 40 hours tasks. All jest aside, 8h+ tasks should be broken down into atomic subtasks, corresponding to different behaviours.
The inestimable task may, however, arise. Having faced nothing like it before, it is time to light the beacons of Gondor ask for help from your teammates, members of other teams in the department, or, if you find it necessary, even people in other departments. A potential hazard at this stage would be to completely rely on others' judgement instead of your own - accepting help does not mean that estimating the task is no longer your responsibility.
Evaluate the advice and then try your best to decide on an estimate. If you later realise that this initial estimate is laughable, re-estimate the task.
Other than that, a basic structure for subtasks should be used, in order to separate different kinds of activities. One example of such a structure, which our team is currently using, looks like:
- Technical documentation
- Dev testing
- QA testing
Some tasks might also include bugs subtasks.
3. Is the description of the task(s) sufficiently clear? If the task has been assigned to you by someone else, are you sure the description is complete and contains no assumptions?
If I only had room for two words instead of this whole article, I would use ANALYSIS and ASSUMPTIONS.
Only when you completely understand a task are you able to provide the best solution and, at the same time, the best estimate. Leave nothing unquestioned, make no assumptions.
At the beginning of the task, during analysis, identify every last piece of fuzzy information in the task description and ask for clarification from the client, preferably somewhat in the form of
“Users will never be able to close the pop-up, is this correct?”
“From my understanding, the shipping costs will be hidden from the user, is this the desired behaviour?”
This approach is a whole lot better than asking the client one question every hour about the task, as this provides both us and the client with more uninterrupted work time.
4. Is the task (or are the subtasks, if applicable) estimated?
The first task to estimate is the analysis task. The analysis step is complete when you have a detailed overview of the solution. Estimating the analysis task should provide the answer to “What am I supposed to do?”, whereas completing it, the answer to “How am I going to do it?”. Prevent wasted time by constantly checking for the answers of these two questions. If you have been writing code for the past hour, closing the analysis task is long overdue.
Start by quickly assessing your setup:
- Is your local/virtual machine setup ready, i.e. do you need to install software or change your existing configuration?
- Is your database ready for implementing the task? If you have to alter it, does it affect any reindexing processes?
- Do you need help from the IT support department? (IP address issues, stage environment setup, etc)
These, and other similar assessments, are to be considered before providing the estimate for the analysis task and must be dealt with prior to any implementation.
Break down the implementation into the smallest steps possible, really thinking about what you have to do in order to complete it. This actually helps a great deal to accurately estimate anything.
5. Do you need a new module? If so, is it a subcomponent of a Magento component (catalog, checkout, etc) or something entirely different?
You want to keep similar functionality in the same module. Think where your code should be written, don’t add a different behaviour to an existing module, just because you don’t want to create a new folder. Hear that, me from the past?
6. Do you need a new branch (is this an entirely new and relatively independent functionality) or can you keep working on this branch?
Despite it not affecting the estimation, creating a separate branch for a different functionality maintains a healthy task approach: keep the code where it belongs.
7. If you need to overwrite classes, have you checked for existing rewrites with magerun?
A great tool for any Magento developer, magerun also helps checking for duplicated rewrites, using the following command:
This helps ensure that overwriting classes will produce the expected behaviour.
8. Have you checked whether there is a backend configuration affecting the behaviour you are trying to implement/fix?
Be familiar with Magento and the project’s backend configuration settings and take them into account when implementing or fixing a behaviour. For example, if you’re trying to “fix” that Magento is displaying 2 items in cart, even though you have 8 (2 products, each having a quantity of 4), you might want to check the Magento default configuration from System -> Configuration -> Sales -> Checkout -> My Cart Link, where you can choose between “Display item quantities” and “Display number of items in cart” (been there, fixed that).
9. Are you sure you are aware of every area this feature/bug affects? (e.g. layered navigation is displayed on more than one page)
Always check all the consequences that might appear after changing a behaviour. For example, search for all the appearances of a block when modifying its content, or check all usages of a function after overwriting it.
10. How are you affecting/are you affected by already implemented functionality related to the same task? (always check other tasks before you alter/implement a behaviour)
This question could be written as an affirmation, with only 3 words: know your project. If you pay attention during daily scrums, meetings, and team discussions, there is absolutely no risk of creating a task for an already completed feature, or reporting a bug that has already been fixed.
Then there’s legacy code, which may leave significant dark shadows in the code, shadows that need to be discussed with the project owner, in order to shed some light on layers upon layers of business logic that might not be revealed by the code alone.
Keeping tabs on estimations
You can also track your estimations, as it is a good way of improving them. I used a Google Sheet to track the progress of my estimations, showing differences between estimated time and logged time and why the difference has occurred.
Tracking my estimations weekly helped me notice some recurring patterns, such as forgetting about testing duration (as seen above), or underestimating complex tasks. Taking these into account significantly improved my ability to correctly estimate tasks.
Tip: if you’re constantly overestimating, reduce your estimate by 25%. Same for underestimating, but increase the estimate by 25%. Still not estimating properly? Keep reducing or adding time, respectively, your estimations are bound to improve.
To sum up: Analysis. No, seriously. Analysis
Even if I’m pointing it out again, it feels like I’m still not emphasizing its importance strongly enough, so that’s why I’m adding it here again (also for the readers that skip to the end). You really have to completely understand a task in order to be able to provide a good estimate and, of course, a suitable solution for the client’s needs.
I wish you good fortune in the wars estimations to come!