Archive for the ‘Technology’ Category

3 Common mistakes when making estimations

Sunday, March 1st, 2009

Currently I am creating an Excel sheet that I am using to monitor the progress of the project I am currently working. Working on this Excel sheet made me aware of some common mistakes people often make while making estimations. Here are 3 of the most common mistakes:

1. Forgetting that you will probably NOT be working full time on your project.
When you work 8 hours a day, it is often the case that you won’t be working 8 hours full time on your project. People disturb you, you have some meetings you need to attend, you spend some time answering email, you’ve got a brainstorm session, you need to go out to meet the customer, etc. Not working full time on your project means that your focus factor is not 100%. If you call everything else a ‘disturbance’ of effective work time, it might be interesting to figure out how much of your time is spent on disturbances and how much of your time is effectively spent on your project. The project I am currently working on will eventually turn out to have a focus factor of around 80%, which means that 20% of my time at work is spent at meetings, etc.

2. Forgetting the number of hours you have available
If you’re working in a team where some of your team members are part time employees, you will have less available hours to get the work done than a team consisting only of full time employees. Although this sounds logical, available hours is something that is quite often not taken into account.

3. Forgetting that productivity / speed will change over time and can be hard to estimate in advance.
If you’re starting a project with a new team, it will be difficult to estimate how fast your team will work. Once you have worked together for some time, you will (if you measure it) gain some knowledge of how much work your team can complete in a certain period of time. Without this experience as a team, you have to base your estimation on wild guesses and experience with other teams that may be different than this one. It is also very hard to estimate how long something will take when you’re going to do something that is entirely new for you: will it be easy? Will it take lots of study time to master it? Also, you will probably get better at the tasks you’re about to be doing. This means that an estimation of 4 days in the beginning of a project could be only 3 days once you’re familiar with the tasks at hand. Making relative estimations can be a solution to decouple time from size. If you estimate in absolute or fixed days, you are actually ignoring the fact that you’re team will get better and faster along the way.

Example:
Say, you estimate that some task takes 4 days. Now, if you have a focus factor of 80%, this means that the work will take 5 days to complete. Now, if this person only works 4 hours a week, this will mean that if he starts on Monday, has a focus factor of 80% and 1 part time day off, then the task won’t be finished until Monday next week in the end of the day.

So remember that you always take into account that you won’t be working full time on a project, and that you have a (limited) number of hours available for your project. Also take into account that estimations at the beginning of a project may be unrealistic further in time. Remember this when determining a deadline, or deciding which parts of the project will be skipped in order to make it to the deadline.

  • Share/Save/Bookmark

Interactive art and technogoly: Messa di Voce

Sunday, February 22nd, 2009

I have stumbled upon this highly creative way of combining interactive technology with the arts. And now it popped up again in my own RSS reader again, and I thought: this is absolutely worth posting, so here it is: Messa di Voce (by Golan Levin, Zachary Lieberman, Jaap Blonk and Joan La Barbara).

Messa di Voce

Messa di Voce is a performance and installation in which the speech, shouts and songs produced by two vocalists are augmented in real-time by custom interactive visualization software. The visualization software used is Processing. Really a must see!! If you’re in NYC, you can watch the performance live and for free on February 23rd, so be sure to be on time!



Messa di Voce (Performance), Excerpts from Tmema on Vimeo.

  • Share/Save/Bookmark

Effective project work-break-down

Sunday, February 15th, 2009

When you’re working on a project, one of the things you always must achieve is flexibility. Why? Because you never know what the future may bring you: functionality may be added, priorities may change, the deadline may be set earlier than originally was agreed upon, team members may get sick, etc. In other words, you must be able to cope with an uncertain future, while still being able to deliver a useful product or service. The way you break down you project into smaller parts highly influences the amount of flexibility you will have, so good project work-break-down is crucial!

pie_slice

In a current project I am working on I was given a predefined work-break-down of the project. The thing with this work-break-down that bothered me was that it was a break-down based on components, instead of User-Stories, behavior or functionality. The project was divided into components like a GUI component, a core back-end component, interface with other applications component, etc. What’s problematic here is that in order to have the smallest working application possible (the most critical parts), a little bit of all of the components was needed. So either I developed the most critical application while none of the defined components were finished, or I could develop all of the components but then I would be doing much and much more than just the most critical application. There are several problems with this approach:

  • prioritizing is hard, because everything seems to have an equal priority since all components seem to be needed
  • it is hard to change priorities because all components seem to be needed
  • you are unable to drop one of the components because all components seem to be needed. After all, just having a GUI component without a core back-end component for example makes it quite a useless application
  • it becomes difficult to finish a component since they contain both critical parts and less critical parts, so all components seem to be needed. (if the GUI component contains both critical parts as well as eye candy, then this way the eye candy must be completed as well in order to finish the GUI component).

Conclusion: all components seem to be needed! And that doesn’t really sound like flexibility!

So, what should you do in order to be more flexible, be able to prioritize more effectively? You should: break down your project based on User Stories, behavior or functionalities.

This allows you (or actually a product owner, end-users, clients or whoever is responsible for it) to prioritize behavior or functionalities of the application. The guiding principle behind this approach is: deliver the simplest, most critical working application as soon as possible, and then add features to it to make it better. This will probably mean that the part with the highest priority contains a little bit of GUI, a little bit of core back-end application, a little bit of interface with other systems, etc. This part should be finished first, and then other parts should be developed in order to make it better, more beautiful, more user-friendly, more whatever.

For example, if I were to build some sort of search application, I would build the most critical part of the search functionality first (highest priority). This would include some GUI with input fields, a software component that has the searching logic, a component that contains an implementation that connects to some data source, as well as a GUI part that displays the result. Now lower priority functionality would be pagination of search results (back-end logic as well as GUI), filtering search results (back-end logic as well as GUI), etc. In other words, once the basic search application is ready (tested, accepted, demoed or whatever), you start adding additional User-Stories, functionalities or behavior.

The great advantage of this approach is that you can easily change priorities (”sorting is more important than filtering, so do that first”), you can drop functionalities while still have a working, useful application (”we’re not going to make it to the deadline, so let’s drop the sorting functionality for now, we’ll release that after the deadline”), and you can truly finish individual parts of the project (”sorting is now finished and accepted, so we remove this from our todo list”).

  • Share/Save/Bookmark

How to make better estimations

Friday, February 13th, 2009

If you were given 10 tasks and asked how long it would take you to complete these tasks, the most common thing to do is to estimate the duration of each individual task. You may divide the task into activities and estimate those, you may discover some dependencies and once everything looks great you commit to your estimation. Now, as you start working on the tasks, your project eventually fails: you run out of time, the deadline has to be moved further into the future or you want more people on your team in order to deliver on time.

Sounds familiar?

Now most of the time when people make estimations, they usually estimate in absolute days or hours. But there are several danger with traditional estimations:

  • if your planning is based on activities rather than features, you’re risking the fact that activities don’t finish, at least they don’t usually finish early.
  • if there are many dependencies between activities, lateness is passed down the schedule.
  • if your tasks are not prioritized by their value to the users and customers, but by the convenience of the development team, you have no option to allow users and customers determine the order and sequence of the work to be done.
  • if you ignore uncertainty and assume that initial requirement analysis led to perfect specifications, you will be surprised by reality.
  • if your estimates become commitments, which is often the case, you are mistaking the fact that an estimation is a probability, and you can not commit to a probability.

A good planning process and better estimations allows: reducing risk, reducing uncertainty, supporting better decision making, establishing trust and conveying information.

One way of making better estimations is to make relative estimations. With relative estimations you estimate size and you derive duration, instead of estimating duration. So for example, a user-story of 10 points is twice as big, complex or risky as a user-story estimated 5 points. There is no unit for relative estimates, no days, no hours, etc.

An iterative approach is probably the best way to deal with uncertainty. During each iteration you can determine how many story points you’ve been able to complete, this is the velocity, the derived duration. For example: 3 stories of 5 points in 1 iteration means a velocity of 3 * 5 = 15. The velocity corrects estimation errors, and is the way to determine the speed of your team and to make predictions about the future.

The benefit of relative estimations is that you separate duration from size. This allows you and your team to deal with the fact that during the project you are learning and your understanding of the problem domain increases (in other words: you get more work done later in the project than early in the beginning = increase in velocity). Also unforseen things that may happen, will be a change in velocity while the relative size of the user-stories are not changed.

  • Share/Save/Bookmark

Do you know what you’ve been listening to on Last.fm?

Monday, January 19th, 2009

Last.fm visualization

I have a passion for the synergy between technology and art. And while browsing the Internet last week, I stumbled upon the website of Lee Byron, a Carnegie Mellon University student. This guy has made some very creative visualizations and graphics. In 2006 he was asking himself: “what have I been listening to on Last.fm?”. He chose visualization as a means to figure that out, and has recorded a short video of the data-mining process. He used Processing for his visualization. Enjoy this inspiring visualization!



Last.fm data mining from Lee Byron on Vimeo.

  • Share/Save/Bookmark