The first rule of estimates is they are estimates! The second rule of estimates is no one is good at them. You will not know how long something is going to take until you are done. But there are things you can do to try and get better at them. The first thing I tell my teams to do is to break everything down into tasks that are 4 hours or less. Stop accepting 5-day estimates on anything. Force the developer to break the item down into tasks that are 4 hours or less. This is going to do several things. First, the developer will be forced to consider each aspect of the effort to achieve the goal. I have witnessed a 5-day task, once broken down into tasks that are 4 hours or less, end up being a 7-day task. That is ok. I would rather know the task is 7 days’ worth of effort before we commit to delivering it. Had I accepted the 5-day estimate only for the task to take 7 days, we would have had to push items to the next sprint that we committed to deliver in the current sprint. That breaks the trust of the team to be able to deliver on what they promise.
Breaking down a task into 4 hours or less also allows other team members to help. If the task was to create a login page with an estimate of 5 days, that will be worked on by an individual for 5 days. Each portion being completed in serial instead of items being worked on in parallel. If the developer broke down the tasks into creating the database tables, writing stored procedures, creating UI, writing unit tests, implementing encryption, etc., other developers could start to work on each portion of the task. Instead of getting the login page after 5 days, we might get it much sooner as multiple team members work in parallel.
Another benefit of forcing developers to break down the tasks is being able to quickly know if we have a problem. Given the normal things we are responsible for in a typical day – attending meetings, answering emails, eating lunch, and the like – you never get 8 hours of productivity in an 8-hour day. To expect otherwise is naïve. In an 8-hour day, I would expect to get 4 hours of heads-down coding done. Therefore, a developer should be able to complete a task that is 4 hours or less on an average day. Imagine you are leading a Scrum team and you have a developer working on a 5-day task. When would you know that you have a problem? Not until the Monday of the following week. Why? Because in the first Scrum where the developer answers the three golden questions:
1. What have you gotten done since the last meeting?
2. What do you plan to get done before the next meeting?
3. Is there anything stopping you?
The developer could answer “nothing” to all of these! It is the beginning of the sprint, so they have gotten nothing done before this meeting. They are working on a 5-day task, so they expect to get nothing done before the next meeting. And I would hope there is nothing stopping them at the beginning of the sprint. The developer could say the same thing all week long.
However, on the following Monday when they say they are still working on task 1, I am now worried. We have burned an entire week and have not completed this task. Now I must assess how bad this current situation is. How many other tasks are now going to have to be pushed to the next sprint? Had the developer broken down the task into tasks that were 4 hours or less in that first Scrum, we would have a different meeting. The answer to the second question should be task 1. On Tuesday, when they answer what they got completed and it is not task 1, we know immediately that we need to address a possible issue rather than a week later.
Another benefit is the tasks can help confirm the team is working from the same Definition of Done. When I ask when you are going to be done, I am assuming we agree on what done means and that we are all estimating towards the same DOD. So, when you give me a 5-day estimate, in my mind that is time for unit testing, experience review, and everything else covered in our DOD. Once the feature ships and bugs are getting filled against that feature, I am now confused. But the 5 days did not contain the time for unit tests. Had the developer broken the tasks down and I did not see a task to write unit tests we could have addressed this issue much sooner.
I want to be very clear that I am talking about estimating tasks using hours and not product backlog items using story points. Story points are an entirely different subject that requires a separate post. If, at this point, you are thinking, “But there are 8 hours in a story point,” you are not ready to use story points. Trying to convert a story point into hours would be the same as telling me the temperature outside in inches.
If your team is struggling with estimating, you might give this a try. I have seen it firsthand turn a team around. Five days seems like such a long time, but it is not when you are trying to cram seven days’ worth of work into it. Telling you what I can get done in 4 hours is much easier than telling you what I can get done in a week.