One thing that comes up in almost every organization I talk to about Scrum is on task estimation. We often paint a picture of Scrum as being pure and simple, and talk up affinity grouping and story points, making sure people know that a story point isn’t directly related to a number of hours. The next thing we do during a sprint planning, though, is to talk about hours estimations on tasks, which can cause a little confusion. The trick is in realizing that there is a right tool for every job – understanding that is the big key to not only make estimation work, but to free yourself to try a few different methods of estimation in order to improve your efficiency.
First, I want to be clear, and state that not everyone does task estimation and breakdown the same way. That’s ok. In fact, I love that. I think it is a great benefit of Scrum that a team has a great degree of flexibility to make well-reasoned changes, and then consider the results. It makes everyone feel more committed to the final choices, as well as more than just a drone – each team member is an integral part and an important voice. That being said, I want to spend some time describing my thoughts on task estimation.
I personally like to track an original estimate, remaining work, and (when not onerous) invested work. That last one is a sticky subject for some, and I am normally prepared to compromise on it Understanding the remaining work to be done is really critical for daily planning, and we try to make sure it doesn’t get used as a stick to beat someone over the head with – having a tracked amount of invested work can make it more difficult to resist that pressure. I don’t mind at all if a task is originally estimated to be 4 hours, and after 3 hours there are still 2 hours (or even 5!) to go – we use that feedback at the end of the sprint to reflect on the story, and why the estimate was wrong, and then use that to improve the task estimation process for later sprints.
In teams which are new to Scrum, and may be coming in highly-specialized, having estimates also helps understand where bottlenecks are going to be, so that the team can start to cross-train where necessary in order to relieve that pressure. Finally, I like to track hours because it helps a team think about a work day as 8 hours, no more – having a reliable velocity (in story points, of course) is dependent upon having a reliable and consistent working model that should NOT include overtime. Hours help the team see if they are overcommitting, or are setting themselves up for success. Making the best use of this requires some additional tracking in terms of availability and “distraction time,” but can be started without it. As you identify what lowers your trust in the numbers, you will find ways to improve them.
Story points are still crucial, and are a great way to do both first-round, high-level estimates, as well as long-term projection and averaging. The tighter the timeframe being examined is, the more granular the data that is required in order to make an accurate picture – that is why I like to see epics with business value for a release level, stories with story points at a team level, and task hours at a sprint level. Some teams claim that they are so cross-functional, so cross-trained, and so mature in Scrum that they don’t require task estimation – they just commit and get it done. To that I say, “Great, try a sprint without it; but understand the plusses and minuses first”. Eliminating hours might make planning go a little faster, and maybe even make a more comfortable and productive team – there is great value to that. However, the definitive loss of analytical data which could be used to investigate problems and drive further discussion is one not to be ignored.