Scrum in a hurry

Me and my wife decided to clean the house last weekend.

First, she created a list of everything that we had to do. Our list looked like this:

1. Clean the kitchen
2. Clean the toilet
3. Clean the living room

We decided to start off with the kitchen. I split the kitchen into sub-tasks and made time estimates for each task. My wife prioritized the tasks. The result:

Clean the kitchen

1. Pick up stuff from the floor (5 minutes)
2. Clean the floor (10 minutes)
3. Do the dishes (30 minutes)
4. Mop the walls (10 minutes)
5. Clean the oven (15 minutes)

After one hour of work, I called my wife to show her the kitchen. I gave a short presentation:

“The kitchen used to be oily from weeks of frying, but look at it now! All shiny … I even finished mopping the walls ... ”

Then we sat down to have a little chat about what went well and what we could improve, before we began planning for cleaning the toilet.

As you probably guessed by now, that is not the way it went down. What I just described is Scrum (where I was the team and my wife product owner). It feels a bit strange to apply this methodology on normal life, but why is that? Let's think about it.

The weird feeling comes from the time estimates in the second list. If we just remove the time estimates it instantly feels more humane:

1. Pick up stuff from the floor
2. Clean the floor
3. Do the dishes
4. Mop the walls
5. Clean the oven

Now it is a simple to-do list. Most people I know will need to-do lists for everything that has 7 or more elements, or else elements will be forgotten.

To me, the time estimates made all the difference. The list with time estimates gave me the creeps, because it implies that time is the important thing in this situation. Like not a single minute could be wasted. Hurry, hurry!

Is time that important?

Usually it's not. Usually you simply need the job done, and therefore it does not make sense to create a time estimate for each task. But there might be real life situations when kitchen cleaning requires time estimates.

Say that me and my wife only had one hour to clean the house. I imagine the conversation would go like this:

Me: “Let's get started and then we'll see how far we'll get. As long as the list is prioritized, we will end up with the optimal result.“

Wife: “No, according to my estimates it will take 65 minutes. I want you to finish the oven too.”

Me: “Then my team needs one more resource to help me out.”

Wife: “Hmpf, no can do.”

Me. “Ah. Never mind those stupid time estimates. I might make it, then again, I might not. There is nothing we can do about it anyway, so why bother?”

Where am I going with this? What I am trying to say is that the time estimates and burn down chart are only needed if there is a deadline for the project and there are extra resources that can be added to the team.

If there is no deadline for the project, then I would suggest the following modifications to the Scrum methodology:

1. During the sprint planning the product owner might need to know the relative “size” of the stories. The product owner tend to push large stories to the future, so the relative size is important. It is common practice to use points instead of days, but I would like a slightly different usage of points. Instead of "point" I'll use the word "coin" (invented here), which represents the product owners purchasing power. The smallest story is always three "coins". Some other story that takes three times longer to complete will be nine "coins" and so on. Using this system a coin is totally decoupled from time units.
2. When the backlog is prioritized, the coins number is erased from the Post-it notes. These figures were only used to facilitate the prioritization, and they no longer have any meaning.
3. If the product owner asks how much work will be completed during the sprint, the standard reply would be: “We do not know, but we'll work according to the backlog.”
4. No burn down chart.

Why do I want to get rid of the time estimates so badly? I am not sure, it is just a general feeling I've had for some time.

Some people don't care about the time estimates, but I am one of those people who are distracted (subconsciously) by the estimate. I get somewhat committed to the estimate, and will get nervous if the estimate is incorrect.

I also believe that timeless tasks might be better for the team spirit, since they erase the difference between "fast" and "slow" developers. By erasing the time figure we are decreasing the emphasis on time.

Moreover I think the burn down chart gets too much attention, and does not capture the overall idea of what software development is about. Imagine the CEO strolling by, looks at the chart and turns towards a developer:

CEO: “What are you working on, son?”

Dev: “I'm writing some code that will change human society forever”

CEO: “Well, I can see from your chart here that you are doing a good job.”

Dev: "???"

Sometimes I miss the old days when we used put all our effort on the “what” and “how”, and simply ignored the “when”. Or did we ever? Honestly, I can't remember.