Agile software projects are complex and often involve multiple disciplines and several iterations to complete development. It’s not just the software developer who must estimate their tasks—a program manager may need to allot time for requirements definition or a meeting with the customer, a tester will need to estimate how many test passes are needed and how long they will take, and the team will also need to factor in bug fixes and customer reviews or feedback. In many cases, a feature may also be dependent on another feature that is under development by another team, and their estimates also need to be accounted for.
With all of these variables contributing to the overall task estimation it’s easy to see why it is difficult to estimate the end-to-end time needed for software development.
Like most skills, estimating can be improved with time and practice. There are several approaches to estimating software development. The most common ones used in Agile software development are time, story points, and t-shirt sizing.
Time-based estimates seem to be the most straightforward. With this approach tasks are estimated using person-hours or days. When using hours or days to calculate how many tasks will fit in a sprint it’s important to establish a realistic number of working hours per day. While you may assume a 40-hour work week and 8-hour workdays are the norm, many companies are shifting to new models that allow for learning and development hours or shortened work weeks.
In addition, it’s common for a good portion of every day to be dedicated to meetings and returning emails. How many project working hours may also change depending on which discipline is doing their estimating. For example, program managers may attend more meetings with customers to understand requirements while the team may limit the number of meetings for developers so they can stay focused on coding.
One drawback of time-based estimation is that time does not equal effort. As mentioned, there are many other tasks that take up hours in the day, and just because something is estimated to take four hours does not mean it will be done in four hours. Story points offer an alternative way to estimate the engineering effort required for each user story. The more effort a task will take, the higher the number of points assigned.
Many teams use the Fibonacci scale (1, 2, 3, 5, 8, 13…) to increment their story points. Fibonacci story points help leave a larger buffer for bigger tasks where the estimates might not be as accurate due to more unknowns. Often, the number of points translates roughly to a given period of time—for example, 1 point might approximately be an hour—so teams can still have some understanding of how long a task will take to complete.
At Assembla, our product team recently adopted a hybrid approach, combining the Fibonacci scale with T-shirt sizing for more accurate estimates. Previously, we relied on time estimates, but that method fell short when it came to assessing backlog and sprint efforts. While this hybrid technique works well for us, your experience may differ—every team is unique.
T-shirt sizing is another technique for estimating effort but works at a less exact, granular level. This is the simplest model because usually there are only four options: small, medium, large, and extra large. Sizes are chosen based not just on the size of the feature, but also based on complexity and unknowns – the greater the complexity or number of unknown elements, the larger the t-shirt size.
By default, Assembla’s agile t-shirt sizing estimation tool simplifies size options: S, M, and L. However, you can create a custom field to include a more detailed list of t-shirt sizes, such as XS, S, M, L, XL, and XXL.
Once you have found an estimating approach that works relatively well for your team you can use historical data to examine how well your estimates compare to reality. Looking back over several sprints worth of estimates can reveal trends about where your team struggles with estimation. You can also look back at each sprint during the retrospective and brainstorm ways to improve your estimating for the next sprint. If your team continues to struggle with inaccurate estimates you might want to consider switching to a different estimating approach.
Of course, each type of software estimation technique has pros and cons, strengths and weaknesses. Many teams find that using a combination of approaches will yield the most accurate estimations. T-shirt sizing is great for early in a project when things are well defined and you need rough estimates for capacity planning. Story points work great at the user story level to allow for more tailored estimates without getting too granular and hung up on time instead of effort. Once user stories are broken down in discrete tasks, time-based estimation is easier and gives teams a clear view of what will fit within their sprint planning window.
Assembla offers project managers and development teams the flexibility to use any of these approaches to software estimation. Whether your team prefers to estimate in hours, story points, or t-shirt sizes, you can leverage Assembla for your Agile sprint planning across Git, SVN, and Perforce projects.
If you’re ready to try cloud-based Agile IT Project Management software, start a free 14 day trial of Assembla. Our team would love to talk with you about how Assembla can meet your Agile software development needs.