There comes a time when a team must decide what works and what doesn’t; in this case, do estimates get a thumbs up or a thumbs down in our book? Intrigued? Read on. When it comes to estimating work in software development it can be frustrating and confusing. You never really know if those estimates are indicative of the true complexity and time requirements of a work item unless you test them over time and determine if those estimates are accurate or not.

At this point, we have already prepared the product roadmap, which encompasses all of the work items required for the completion of a project, and have a general understanding of the order of priorities for the development of upcoming features. Now it’s up to our project management and development team to get a thorough understanding of what each task will demand in terms of time and effort to appropriately plan a sprint and communicate timelines to the Product Owner.

First, we used the Fibonacci sequence (0,1,2,3,5,8,13) and assigned a difficulty level to each numeric value. For example, a task that is an 8 is highly complex and requires a couple of days of work versus a 1 which is incredibly easy and straightforward, which requires an hour or less of work. Then we held a Planning Poker or Scrum Poker session, which is “a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development”. In these sessions, we opened up the floor for Q&A about the features and different potential implementation methods. After each participant submitted his or her vote, the Project Manager reviewed the overall scores for all of the items specced, based on previous sprints, determined the work items due. In essence, if in the past we were able to accomplish successfully 40 points, then for the next sprint, we should be able to accommodate 41 or 42. Each sprint should improve upon the previous one and test the team’s productivity.

This all sounds pretty simple; the team agrees on the complexity of a task and the PM analyzes and communicates the deadline to the PO. So far, it’s a thumbs up. But based on our experience, after analyzing historic sprint performances, there wasn’t much difference between assigning a complexity that wasn’t based on time required for completion and just coordinating on the tasks due in the Sprint Planning Meeting based on the technical team’s general input. We learned that it was more important to understand how long something would take, rather than how complex it was. Moreover, in the latter stages of the development cycle, we felt that the Planning Poker sessions interrupting the team’s flow and were consuming valuable time that the team could’ve used to actually work, rather than estimate. So in this case, we give it a thumbs down.

Overall, estimates in software development serve as a guide to understand the complexity of a task and as an indicator of what is accomplishable over a period of time. It tests the team’s ability to comprehend and analyze the tasks at hand and be able to pinpoint its complexity and the effort required to mark as done. However, it cannot be the sole measurement of predictive planning nor accountability. There’s really no harm in having different views on how to plan for a sprint or to forecast meeting deadlines, so the more information you have at hand, the easier it will get to measure and build—estimate and deliver.