Should I estimate my free-time tasks?

When I started introducing agile methodologies in private life and in my family I thought I have to do it the right way. For me this included story estimation. It turned out that for me this is not the right way of organizing my free-time and projects in our family. I want to use this article to explain why. But first, let's make a detour to understand what estimation is and why it is important.

Estimation

First of all: what does estimation mean? In scrum you give a story a number based on its effort. This effort can be affected by risk, uncertainty or complexity of the task. The number you give to a story is called story points. The whole process of giving stories story points is called estimation and is done with the whole team during backlog refinement. This process is also called grooming - funny, I know.

There are different scales that can be used for story estimation. The one I worked most with is the Fibonacci sequence. For estimation this sequence is cut off after 13, which gives you the numbers 1, 2, 3, 5, 8, 13 starting at 1 for the lowest effort.

Let's look at some examples. Say you have to take out the trash. This is a fairly simple task. If my dog had thumbs he would be able to do it himself. Sadly he doesn't.

Taking out the trash is a story that I would estimate with one story point. This story - as one of the simplest - could also be our reference story that we compare all other stories against.

Another example could be to clean the windows of one room of your flat. I guess that's a bit more difficult than the previous story. You have to prepare cleaning water, a rag, a sponge, maybe a towel. Maybe, you also have to get a ladder out of the cellar. You have to clean the windows from the inside and the outside.

What I have done here is a task breakdown of a story. Before you start working on a story - or even prior to estimating if this helps you doing it - you break the story up into small tasks. This usually gives you a pretty good sense of the effort involved.

Let's say cleaning the windows of one room in your flat is a story three times as difficult as the first one. Hence, we give it three story points.

One final example: you bought a new wardrobe that has to be assembled, aligned and filled with stuff. Phew, this sounds difficult! Let's do a task breakdown to figure out the effort to finish this task.

You have to get the packaged wardrobe up the stairs, you have to unpack it, you have to assemble it, align it and fill it. Maybe you need to go to the hardware store to pick up some screws and screw anchors. So, there might also be a risk of delay involved.

This all sounds really complex. You even have to think about getting a friend over to help adjusting the wardrobe. You might say this is more than double the effort compared to our second example, which would give this story an eight on the Fibonacci scale.

You could also argue that, counting in the risk of having to drive to a hardware store to get the right equipment, it is more of a thirteen. In this case - in software development - you usually say that this story is too big to be dealt with in one sprint and has to be broken up to make it better digestible. This avoids that working on the story is spread over multiple sprints. Remember: we want to create value in each sprint. Not finishing a story means no direct value.

Why mess around with estimation?

Estimation takes time and is a repetitive process. So, why messing around with it in the first place?

A corner stone of scrum is transparency. Sprint after sprint you measure how many of those story points you can achieve in one sprint. This gives you an average of story points that you can achieve in one sprint. This amount is called velocity.

Over time you get better and better estimating the effort of stories which gives you the possibility of predicting

• how many story points you can achieve in the next sprint,
• how much value you have already delivered in the current sprint and
• when a certain feature/task can be implemented which is very important for stakeholders (think of your wife asking when she can put her clothes into the new wardrobe).

Those, in my opinion, are very good reasons to deal with estimation.

Estimating free-time

Coming back to the question of this post: should you estimate your free-time tasks? As noted at the beginning of this post I started doing estimation for all my projects that I wanted to tackle during my free-time. It turned out that it was more of a hassle for me and the arguments for doing it where not satisfied at all.

As the time I can spent on my projects varies a lot I wasn't able to achieve a stable velocity. This basically nullified all the advantages of estimation described above. Usually, I even do not have any stakeholders for a story. Additionally, it felt more of a burden to have another thing to do before starting. In the end, for free-time projects, it doesn't really matter when you are done. And most of the time the doing is the fun part.

Do you have experience with doing estimation in general, at work or in private life? If so, does it work out for you and what do you struggle with?

Post image taken by timlewisnm published under CC BY-SA 2.0.