Time tracking is something we’ve always done at our Web design and development agency, Pelago. When we transitioned into a SaaS company five years ago, with our flagship online software Intervals, the time tracking practices followed with us. Agile development just came naturally to us, and our time tracking habits dovetailed with our rendition of Scrum. As we continue to iterate over our Scrum processes, we have discovered one indispensable fact — time tracking is the key to better sprint planning.
In this post…
Points as time
Sprints are defined by the number of weeks they will take. Agile development practices recommend planning sprints lasting two, three or four weeks. Since we are designating the length or our sprints using units of time, it makes sense to us to do the same for our stories. Points equal time. To avoid the trap of over-analyzing the amount of time for each story, we have a preset list of bracketed points to choose from — 0, 1, 2, 4, 8, 24, 40, 100 are the only estimates allowed. This helps our development team answer the question “how big is this story?” as well as thinking through how many hours this story will require.
In our experience, the estimated amount of effort is different from the actual amount of effort. The word “effort” can be too abstract and interpreted differently by our development team and Scrum master during the sprint planning process. Time tracking data gives us an objective unit of measurement and common ground to keep the team’s sprint commitments in check. What is lacking in using points is that we can’t look back at past sprints and compare actual points against the original estimate. Time tracking data let’s us do that. Our sprint plans become more refined and accurate moving forward because we have an unobstructed view looking back.
Velocity as time
Velocity is defined as the amount of effort a development team can commit to one sprint. We look at velocity as the average number of weekly hours worked by our team for the past several weeks. Because we’ve tracked our time on past sprints, we know how many hours per week our team can handle. Our three-week sprints have a velocity of three times that number Our sprint planning is complete once we have committed to a list of tasks whose total estimated points are equal to our velocity.
Time tracking adds perspective and value to Scrum teams using velocity to plan and track sprints. Let’s say, for whatever reason, your team loses a member. How much effort did that person contribute to your overall velocity? If we’ve been tracking our time using online software, the answer is just a few clicks away. We can find out how much time that person contributed to each sprint, as well as the type of work they performed. The Product owner and Scrum team can use this data to adjust the velocity and plan the next sprint more accurately.
Predict, track, learn, repeat
Scrum sprints are an iterative process. The goal of Agile development is to continually deliver something of value every few weeks. Teams iterate over the product to meet these goals, but they also iterate over their process. Each sprint should be more successful than its predecessor. Sprint retrospectives are held at the end of each sprint to discuss what was successful and what wasn’t, and how we can improve. Time tracking data gives the team an objective measure of the last sprint and provides a platform for more accurate point predictions on the next sprint.
Time is the common unit of measurement we use for establishing sprint length, velocity, and points. Once we have all three on the same terms, our development team can fully understand expectations, and the Scrum master has a baseline for holding the team accountable to its commitment.
Photo credits:
Time passages by Robert S. Donovan
Velocity by Phillip Clifford
Today’s Repeating Pattern by Kevin Dooley
