Member-only story
Estimates Are Estimates!
A lesson learned as a Scrum coach
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 delivering 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…
