How Much Time You Spend Tracking Time? (Is It a Good Use of Your Time?)

I talked with couple of friends of mine who reported that their companies track everything they do. Ranging from pretty much going to toilet to drinking coffee to sitting in meetings to other stuff one does at work, they track everything.

And… then they (seemingly) don’t do anything with the numbers (or read them wrong, or give such penalties that people start to lie about numbers which effectively leads to the same thing).

I know some guys like to track their time (and it can be a good thing, maybe), but I’ve always liked to track more about the result side of things. Of course both are important if you want to analyze (it’s important to know how much certain project took resources and compare this with the results), but if you’d need to pick one: pick the results – count the achievements accomplished in certain time for example.

Some managers make it a must thing to track everything in micro level. You need to calculate how many hours you put into planning and brainstorming and meetings and coffee drinking and whatnot. Sometimes it starts to puzzle me how much these guys put time into tracking time (maybe some companies actually track time they put in tracking time…).

If they actually use the numbers, then good… but if they first require everybody in the team to give a detailed numbers of how many hours they spent coding different things, I think they are quite in the wrong track.

If they only ask Joe to report his 151 hours of programming (and do nothing), then things are bad.

If they actually use Joe’s numbers to estimate how much something took time, and what Joe should do (and whether he should do more programming) then we are getting somewhere.

Although… people work in teams. Team consists of several people. Tracking Joe’s, Tim’s and Eric’s time separately doesn’t necessarily help much. Knowing that these guys spent 308 hours last month to program doesn’t help much either. If they know that these guys managed to finish X number of features in 308 hours can be helpful. You can use it to estimate future features (and their costs) and help make decisions. If on the other hand you “do this stuff anyway” – what’s the point of tracking time?

How much your team spends in tracking time? Is it really useful? Do you use the numbers for something?

Not Gonna Release My Game Before Summer Vacation

Half a year ago, I had a goal to get Dead Wake out in the end of February (or at March). In March, I had a goal to get it out in June. Deadlines, deadlines.

I can see that this is quite expensive to keep in developing, but overall I feel it’s still been good this way: I don’t want to release something I wouldn’t feel proud of. I made some really good progress in June, and tackled almost all the items in my Dead Wake task list. I haven’t release the game, since some things happened:

  • I experienced on major bug (I wrote about it), but eventually got it sorted (it was crazy collision issue, and it’s still bit unclear what exactly cause it – but it’s fixed, and I know what line of code did it, so I’m fine with that). This caused a couple of weeks delay in my progress.
  • Feature creepish thing in me sneaked in: I added some new things that I think will make the game better (ranging from new type of zombies to different weapon handling and reloading and perks and stuff).
  • It’s too near holidays…
  • …and I still need some things done.

So basically, I think I might have been able to get some sort of sellable version out if there had been the collision issue and if I had not choose to do some additional features. Maybe.

I still have some grand plans about the level system which I need to do, but I keep reminding myself about what I’m doing here – and that it’s too easy to add “just one new idea” in the game, but you gotta remember how long you plan to work on the game.

The game is not finished: there’s still some key tasks that need to be done. I want to feel proud about the game I’m released, and not want to try rush it. I’ve planned to take some break in July and spend less time on computer (recharge batteries for the whole year), relax and do sunny holiday stuff. I’ll work on the game a bit on July, but will continue full charge right in the beginning of August.

I actually pondered whether I should try to do the release in the end of June as I planned, but then I remembered a piece of advice I once gave to friend of mine. He was preparing to get on a holiday and asked if he should release something a week before the holidays.

I said: “You’ll ruin your holiday if you release now”.

He agreed instantly.

So do I.

Do You Make This Mistake When Delegating Tasks?

I discussed with one (non-game developer) guy who had got assignment to “be at this place at 10:00″. After getting this piece of information, the guy was also told “it would be good if you could come little earlier”.

“Little earlier”? What does that mean? Is it 5 minutes earlier? 15 minutes? 30 minutes? Why not simply say “be here at 9:45″, that would make the task more clear.

Same thing can happen in game production. Sometimes a programmer might ask “we can do this minimum quality, but do we need to do it with higher quality?”, to which game producer replies “Do the minimum level, but it would be nice to get higher quality.”

“Would be nice”?

In this situation, the programmer didn’t know what to do, and when he asks for help he gets confusing assignment and probably goes home to burn some ants with a magnifying glass to release stress.

If the producer is the one who makes decisions, then he is the guy who needs to say for example that “Do the minimum quality” or “Do the higher quality”. Or, if he needs to think about the resources he could say “Do the minimum quality, but if creating higher quality takes less than 3 days then proceed”.

Giving specific details is really important to avoid any confusion.

(And to help ants to survive.)

The 3 Things You Need to Remember When Recruiting More Team Members (Video)

I hired a new team member to help me with coding Dead Wake. Unfortunately the hiring was a horrible failure, and the new team member wasn’t paying attention to me and couldn’t last long with me. As painful it was, I decided to share these 3 important things one gotta remember when getting more people in the team.

Check out this video, and make sure you don’t waste time and know what to expect when getting more people in your team.

How Long Will That Take? (How to Figure Out What Estimations Really Mean)

One of the first elements I got really interested about project management and scheduling was estimations. I remember doing some university papers about estimations many, many years ago. For some reason I was really interested about(1) estimating how much time doing some stuff takes and (2) how much time it really took.

(Writing that down makes me feel little stupid now that I think of this…)

Anyway, estimations. I wrote earlier about using points in estimations, but points have a tiny flaw: developers might feel that they don’t know what a “point” really means. Because of that, it can be useful to use term “day” instead of a point. (Or a “development day”). Nothing changes, except you just call points as “day” (or “development days”)

I know some “agile gurus” will argue that this is bad behavior, but what I like to do is to try things in practice and see what happens. With points, there’s also problems – and one problem is that it might be difficult to really understand points and their relative sizes.

So, now we can use a “day” in our estimates. One team (of 8 guys) could have a following estimates:

  • Level big boss, 20 days
  • 3 new weapons, 10 days
  • Exploding barrel, 5 days
  • Minimap, 8 days

Total of 43 days.

Now, after one calendar month of work they end up finishing things in following times:

  • Level big boss, 55 days
  • 3 new weapons, 30 days
  • Exploding barrel, 9 days
  • Minimap, 22 days

Total of 116 days spent in these, and they are finished. Team has used 160 days in this one month (after taking account all the breaks, sick days and so on), so their velocity (or “how much stuff they can do per month”) is 43 (development) days – the estimated work amount. The next month they finish stuff worth 51 (development) days, and 47 the month after that.

Now, after a few months we can see this team of 8 guys (who work 160 days per month) can finish tasks worth close to 47 (development) days. We can also calculate that estimation of 1 day equals to 3.40 real days (taking into account everything extra goes to meetings, hiring, discussions, bug fixing and so on).

I won’t go into detail about how the estimations could be done (that’s a topic for some other blog posts), and won’t go into detail about the possible problems of this style (and how they can be solved) in this blog post, but the basic idea is that you keep estimating tasks (and make sure that the relative sizes are proper: you want to make sure that your estimations are in line with each others) and then track the “total amount of days the team members have done”.

From these numbers it gets easier to give estimates. From these figures you can see what estimations really mean in a long run. For this team, a 5 day task really means close to 17 days of work (taking into account everything) on average.

Putting a Deadline Is Not Impossible (It’s Pretty Easy Actually)

Lamonte pointed out that putting a deadline (or meeting the deadline) in reality is nearly impossible. Projects are late, so putting a deadline does no good.

I have a pretty confusing on this opinion. I totally agree and totally disagree with it.

First of all, I agree on this because often in the real world all the features are fixed: you simply need to do certain features and thus it’s practically impossible to set a deadline (and might be foolish to do so), instead the best you can do is to give a rough estimation about when the project could be complete.

On the other hand I disagree that it would be impossible to set a deadline and meet it.

I think in reality the deadlines are missed because managers/publishers/sales people/producers/you-name-it have promised certain features (and more), in certain time (or less) and that your project can use only certain amount of money (or hopefully less). Meeting the deadline is impossible because for some reason all the 3 elements: features (quality), deadline (time) and resources (money) are fixed – which can be impossible equation.

It’s bit like saying that:
- You need to go 100 meters in 5 seconds.

That’s practically impossible to reach I think. But, if we could agree to change those 100 meters to 10 meters, I’m sure we could do that. Or, if we could get 50 seconds to go those 100 meters – no problem. Or, if it’s not “me” who needs to do this, but instead we could get a brand new Ferrari that’s going full speed, going 100 meters in 5 seconds would be no problem.

According to this, having a fixed deadline is not impossible. It simply means that we might need to use more money (hire more people, get better equipment etc.) or that we reduce features (and have lower product quality).

Setting a deadline is more than possible if we decide to have one, in fact – I think it’s very easy: you just pick a date, and that’s it.

After that, it’s a matter of decisions. If we want to stick with that date, and if we agree that the certain date is the fixed piece, then the other elements (money and quality) will need to reflect this.

In my opinion, having a deadline is not impossible. It’s more like a choice.

Have You Ever Been Assigned to Do Useless Tasks? (Here’s How You Can Fight Back)

When team leads come to say that they need something. Then later they complain why the artist gave them something else (something that wasn’t what the lead want). Then they go and tell what needs to be changed and the artist asks “Why didn’t you say that in the first place?”, to which the team lead says “geesh, you didn’t ask!” and goes away. Then the grumpy artist thinks that “well, I would have asked if you bloody moron could have told me that there will be other changes as well…”

Hopefully that above situation isn’t too familiar to you.

Dogbert’s management book says to the managers that “If the worker cannot understand what you say then the fault must of course be in the receiving end”. That probably won’t help anything, but there is actually one thing the “worker” can do:

Keep asking ‘why?’
When somebody gives you a task it doesn’t hurt if you sometimes start asking a sequence of “why” questions. It can actually help the team lead (or client or whoever is giving the assignment) to figure out what they really want. They might be fixed on certain way of thinking, that they’ve forgotten why they really want the stuff they are asking.

Producer could say that he wants the 3D artist to make sure model has finger bones. By asking “why” (and not assuming that “it’s because he wants animated fingers”), he might tell you that “later when we assign objects like rings to the character, we can use the finger bone to locate the proper place”. Here artist could say that “we don’t need bones to locate the ring, we can use other technique” or he could say that “why don’t we simply paint a ring texture in proper location, that would work”, to which producer would say “oh… true… nevermind then”.

The key is to ask why they want something.

The answers can sometimes be very surprising.

One Useful Agile Method For Project Estimations

I’ve done (IT/games) project work for almost a decade, and one of the trickiest thing has been (accurate) work time estimations. I’ve been participating in doing estimates for small and big projects, and sometimes there has been more time to do these estimates, sometimes less time.

It’s a tough job
It has been quite typical that in a long run, estimates are really tough to do very well. If you give estimates in “how many hours it will take”, it feels like there’s always something that might be missed. Sometimes there might be new bugs appear that take time. Or, the code maintenance gets trickier. Or something else.

Agile methods help
One useful approach for this comes from agile methods. I think any team (whether they have interest in agile methods or not) can use this system for better estimations.

The idea is to use relative size estimations, not absolute size
It’s been suggested that it’s easier to estimate relative sizes instead of absolute sizes. Instead of saying that finishing certain task A will take 3 days and task B takes 6 days, you could say that task A will take 3 points worth time, and task B will be approximately double of work, or 6 points.

Take a look at the following picture:

Absolute estimation
How many proper blue and red poker chips there are? In this case could go through them one by one and say the number but it would take time and you might still make a calculation error, or some of those blue chips could be damaged and should not be taken into account. Some of them could be missing from the picture. If you want to know the absolute number of blue chips, it would take you some time and the number could still be inaccurate. Same goes for red chips. Or black. Or green. Or whatever colored chips there might be. You’d be counting the chips all day, and still make errors.

Relative estimation
Now, how many blue and red poker chips there are if you use relative estimation? You could say that there’s about half (+50%) as much red chips as there’s blue chips (for example, you could say “10 points worth blue chips, and 15 points worth red chips”). Of course you could wonder if there’s more of those black chips (and take a better look and ask others) and say for example that there’s 13 points worth red chips if you feel that way.

Again there could be some broken blue or red chips, but if we are measuring the relative size it has lesser impact. If for every 2 broken blue chips there’s 3 broken red chips, our estimate would still be correct. If on the other hand we see that there’s more broken blue chips compared to other type of chips we can re-estimate the points for the blue chips for example.

Back to game development: The idea is not to know how many hours one task will take. The key idea is to establish a common baseline for making evaluations (as in “this task takes 2 points, this one 1 point, and this one here feels 3 times bigger than the previous 1 point task so let’s call it 3 points task”) and use points instead of hours.

Getting to hours
But what if you want to know how much time it takes? Patience grasshopper.

The ‘how many hours it takes’ will come from experience. The goal is to keep estimating using points, and then track your progress as time goes on. After some time, you will be able to say that “okay, I spent 200 hours doing this, and finished 10 points worth of features. From this I can say that 1 point – in a long run – is approximately 20 hours of work.”

Let’s take an example:
This can be useful also when taking into account bug fixing. Let’s suppose you’ve estimated that coding a module takes one week. You finish the module in 5 days and are happy with the results. The bad news are that in the next week you spend 2 days fixing unexpected bugs that were found by the testers. Also, one more day is spent reviewing and refactoring the code since there were some problem areas that needed bit more work. That means the estimated module took 8 days instead of 5. The last 2 days you spend coding some other smaller module that was estimated to last 1 day.

With a points system you could have said that the first task takes 5 points (for example), and that the other smaller task takes 1 point. Your estimate is bit off (since the first task took 8 days, and the other 2 days – which means the relative sizes are 4:1.) but you can’t always know exactly how many points something takes and you can trust that this number gets better as time passes.

After a few more weeks, you could give a pretty accurate number that on average you managed to finish 6 points worth in two weeks, which means you’d have basis for evaluating how much work you can do.

The more I’ve been using this type of estimation, the better I feel about it.

For those of you who are interested in agile methods, I suggest reading Mike Cohn’s blog (and his books). He has plenty of good information on how to use agile methods.