Estimation is one of the most difficult aspects of the Agile process. The natural tendency of team members is to include only the time it will take to complete the actual work for the item they are estimating. I have a process where I break each work item down into 4 parts to help me get a more accurate estimate. This is a process I use all the time in my current role as CTO of CUE Marketplace and I hope it helps you in your Agile estimations.
Understanding the Big Picture Estimate
I want to know every aspect of the work item that I’ll be completing, so I add any time it would take for me to fully understand it. It’s a huge time saver if my Product Owner has written the work items as user stories. That format helps with the “who,” “what,” and “why.” Other items that could take time include understanding any UI designs/clickable demos, reviewing usability tests and getting to know the “who” part of the story by researching the customer or persona.
Architecture/Technology Research Estimate
I ask myself if I fully understand the architecture and technology involved with the item. If the item isn’t an easy add to the current application, I’ll add some design time to the work item. I also try to understand the technology involved. Do I need to learn a new framework or plugin to complete the work? Do I need to understand an API that needs to be connected? This work design and research can be a large percentage of the overall work item and is usually overlooked.
I start my work estimation process by breaking the work item down into smaller tasks. I look for different areas that I’ll need to modify including the user interface, server/API, database, and deployment. After this, I look for refactor opportunities to make the code I write easier to maintain or more reusable later. I’m much more accurate here when estimating smaller tasks and it allows me to create a checklist for success when doing the work later.
I add estimation time for both manual testing and unit testing. I’ve seen some Agile teams break this out into separate work items, but that’s not my preferred process. I also add time to the estimate for documenting testing details to help QA be more successful. I like to document what was accomplished and any other areas in the application that could be affected by the work for this item.