Posts   |   About

"Will we complete this sprint in time?": Modifying GitHub To Work For Us

My team estimates the time to complete an issue using “T-shirt sizing”: we assign size labels “S” (<= 1 day), “M” (2-3 days), and “L” (4-5 days). One quick, albeit rough, way to estimate the amount of time it’d take to complete a sprint is to sum together the number of days these size labels represent (we use the upper bounds to be safe) to find out the number of “engineering days” it’ll take to complete the sprint. To find out if you’ll complete the sprint on time, this number can be subtracted by the number of engineering days until the deadline: the number of days until the deadline multiplied by the number of engineers you have. To make a formula:

eng_days_to_complete_sprint = sum(issue_size_days)
eng_days_to_deadline = days_to_deadline * num_eng

days_left_over = eng_days_to_complete_sprint - eng_days_to_deadline

It’s tedious to calculate these values by hand, especially when the issue list, and its size estimates, is rapidly changing during a sprint planning meeting. At our Product Manager’s suggestion, I created the GitHub Story Points browser add-on to calculate our eng days estimates for us:

An example of GitHub Story Points in use

You can get it on and find the source on GitHub.


I mention “engineering days” but this style of estimation can be used for any type of resourcing days – I used this terminology because I thought it’d be more intuitive.

A few more notes on our estimation processes:

This post is written by Michael Comella, a developer at Mozilla currently working on Firefox performance.
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Creative Commons License