3. Making Estimates
"Software estimation,” it says, “is difficult. Really difficult. You just won’t believe how vastly, hugely, mindbogglingly difficult it is.”
Douglas Adams (paraphrased)
So, why do estimations? Estimations will help narrow down the scope of the project. It will give the stakeholders a broad idea of just how big a task the requested project is. They will be able to rethink the project and decide what features are critical for this release and what can be pushed out to further releases.
For the developer, it plays the important role of making you think about the work before you sit down and start programming. By estimating your time, you need to have a game plan in place on how you're going to solve the task at hand. You don't want to be nearly finished and find out that you missed a key component or two and you have to undo hours and hours of work.
Weeks of programming can save you hours of planning
Unknown
-
Your best gauge for estimating is past experience. If you typically take eight hours to program, wire up and test the onboarding process (login screen, registration, forgot password), you can use that as a baseline. Even if you are given a login screen with some unusual requirements, you can do fairly well by just estimating those additional requirements and adding them to the eight hours it normally takes.
-
Task based: Break your storyboard into individual tasks and provide estimates for each task. A task may be doing the design for a screen, the code that makes REST calls, or designing your data models. If your task is an onboarding screen, you may estimate several hours to do the screen layout and four hours to code the login logic.
-
Function points: Break your task into the functions required and estimate how long it will take to write each one. For example, you need methods for creating, reading, updating and deleting data. Estimate the effort needed to code and test each method.
-
Shadow others as they estimate their own tasks. Find out how they do their estimates and ask them to explain how they arrive at the numbers they come up with.
-
Everyone works at a different rate, but you may be able to find estimates for common tasks on-line. These can act as a starting point if you don't know how long something takes. An example would be setting up a backend like Realm or Firebase.
-
Keep track of your estimates and actual time. Determine what caused the two numbers to be different. It may be more than one factor. Whatever the reason(s), if you identify them, you can take steps to improve for next time. The more you understand how you work and your strengths and weaknesses, the better your estimates will become.
Story points are not a measurement of time but of comparative difficulty. A difficulty value is assigned to each story based on the amount of work, complexity, risk and uncertainty. The numbers assigned to a story relay the relative value to another storyboard of agreed-upon difficulty. If everyone agrees what makes up a 10, for instance, you can use that as a baseline to determine which stories are higher or lower in difficulty and assign the number accordingly.
A screen that does little more than display information or gets a user's preferred settings would get a low score, such as 1, since there's not a lot of complexity and it's a straightforward task. Even if there a lot of fields or information being displayed, the complexity, risk and uncertainty is negligible.
The same screen that relied on getting data from one or more external sources and applying complicated ruled-based filtering will have a higher rating.
If the completion of your task relies on another team completing its task and the team has offered no clear delivery date, has fallen behind their estimated date or you have some other dependency, your uncertainty value goes up.
The scale itself can be any granularity. It can range from 1 to 50, 10 to 100 by 10, or be logarithmic. Since the unit of measure is comparative, the axes can be whatever makes sense to your team.
Don't panic. If the delay is going to have large scale ramifications further down the development process, let someone know as soon as possible. If you estimated 20 hours for a task, and 10 hours into it, you realize it is more complicated than you thought and you estimate that you have another 20 hours to go, speak up. Often a solution can be worked out. Resources can be reassigned from less important tasks to pitch in. Someone may have overestimated a task and completed it early. Those hours can be reallocated to your current task. In any case, letting someone know will help inform the customer that there may be a delay. The sooner in the development cycle you fix a problem, the cheaper it is to correct.
At CodeDoesGood, we are all volunteers. We know that life gets in the way and you are never required to hit an estimate. There are very rarely hard deadlines unless we are in a special situation like helping a group that is handling a natural disaster or some other time-sensitive issue. However, estimates are still VERY important because your development team, the project administration team, and the business team will be looking at your ticket to see when the can expect a feature done. You MUST update your ticket with the new estimate as soon as you see that you are not able to make the original estimate.
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
Douglas Hofstadter
If you're unsure about your estimate, assign a probability range. You're 30% confident or 80% confident. The more detailed and thorough your analysis is, the higher your probability that your estimate is accurate.
Typically, in a corporate or office setting, estimates are given in hours rather than days. The reason for this is simple. If a job is going to take you eight hours of effort, that does not mean you will finish the task in one eight hour work day. Between meetings, reading documentation, writing documentation, questions by coworkers, email and other interruptions, you will be lucky to get a solid 4 or 5 hours of programming time.
If you say the eight hour task will take one day, then it will be expected to be completed in one day which is not likely going to happen. That eight hours of effort might be stretched over three days. Eight hours rarely ever equals one day.
Since CodeDoesGood is structured differently and the developers work in their spare time, that method will not be a useful a metric. Work should be given daily estimates. Your estimate should contain the number of days of work and a target completion date. For instance, if you estimate that it will take you two days worth of effort, but you can only put in one day a week, your target completion date will in two weeks.
Your estimate should always have a multiplier built in. That is a buffer that you've baked into the estimate.
If your best estimate is that it will take you 10 hours to complete a task, your multiplier may be 1.5. Meaning you multiply your 10 hours by 1.5 to arrive an an actual estimate of 15 hours. If you are new to programming or just working on an unfamiliar framework or doing something you've never done, your multiplier may even be as high as 2.0. Your multiplier may vary for different tasks.
If you are working with a library for the first time, add half a day to cover your learning time.
-
Documentation: If documentation is not a separate task, do not forget to include that when creating your estimate. Any documentation, including instructions to testers and stakeholders have to be accounted for.
-
Testing: Often, testing time is overlooked when making an estimate. This includes time fixing issues discovered during testing.
-
Planned or unplanned leave: If you plan to go on vacation or will otherwise be out of the office, don't forget to add that in your timeline. Additional time should be added for unplanned absences. Let someone know if somebody is expecting something from you that day.
-
Holidays: Be cognizant of holidays when determining estimates. If your estimate falls on a holiday or in the middle of a holiday season when people are not likely to be available, make sure you plan accordingly.
Do you best with estimates. Even experienced developers have trouble accurately estimating sometimes. Run your estimates by someone familiar with your task and ask if it sounds reasonable.