Rough Sea Games » Tips

Lessons Learned: Asset Loading

Manuel — Tue, 02 Nov 2010 14:45:12 +0000

Handling resource loading in a web project can be tricky sometimes. We stumbled time and time again over new issues. Today, I would like to share some thoughts with you about this topic. These are things that may help you to get asset handling right the first time in your project.

In the beginning, there was our neat little asset loader that early in the development only had to load files locally. From the start we integrated parallel loading of files to speed things up a bit. When we tried it online everything still seemed fine. No worries, ey? Well, the problems started when we hired an external Quality Assurance team of 20+ people sitting behind a single unstable 2MBit line. To our surprise they weren’t able to load our game at all. Using a remote access tool we debugged what happened and fixed, and changed, and tried out until the game loaded somewhat reliably with their connection.

There were two main problems we had to fight at first: “File Not Found” and “Broken Data”.

“File Not Found”
Well, sometimes the Flash loader returned a 404-error for no apparent reason. Next time, the game is started, it would find the file but another one not. Crazy stuff! We did not really find the root of the problem. We only guessed that maybe some part of the internet connection was only able to handle a certain number of parallel http requests. Yet, we were able to work around the problem: When a “File Not Found” occurs, we simply flag the asset as “not loading” again and put it in the back of the load list. When the asset loader is done with all the other files it will try to load the file again. We allow this to happen up to 10 times before eventually giving up for good.

“Broken Data”
Now, that our external QA team was much more likely to be able to play the game a new problem emerged. The data that was loaded was sometimes broken. Pictures looked scrambled; XML-objects threw exceptions on initialization with our loaded data. Again, that was a weird phenomenon that we were not able to find the root of. Yet, our workaround from “File Not Found” worked here as well. We put a try-catch block around the part where we turn the loaded data into real objects and if something fails, the file goes to the back of the load list.

Later, we refined our workaround by adding two more features like “Reducing of Parallel Loading” and “Trick the Cache”.

“Reducing of Parallel Loading”
During our testing we realized that we were able to increase loading stability greatly by only loading on file at a time. Unfortunately, that slows down the whole loading process tremendously. So here is what we did: After every unsuccessful loading attempt we decrease the number of files to load at the same time. So, only users with unstable connections will get slowed down.

“Trick the Cache“
If a load fails, we flag the file so next time we try to load it we try it without the cache. Otherwise we might just get the same broken file again. That is not an obvious thing in Flash since it has its own caching system that is hard to influence and besides, you never know what other caching mechanisms (like proxies) are at work on the way from our servers to the user. Well, by adding a parameter to the request URL (something like “?foo=” plus a timestamp or a random number) you can trick most of the caches to believe they need to load the file anew. (External resource about this here)

Is there any room for improvement?
Oh Lord, yes, there is! For one, we will introduce some kind of hash system to validate downloaded resources at some point in the future. Right now, we only assume that if turning a chunk of binary data into an xml or a bitmap actually worked everything is fine. Well, it’s not. Especially, JPGs files are fairly error tolerant which already did cause broken visuals in the game for some users in the past.

Another cause of problems can be content firewalls. As it appears, some users are not able to download our (I must say brilliant *hehe*) background music while not having any troubles with the other file types. So, I believe we should introduce an optional asset type that will not render the game useless if they’re not found or broken.

Furthermore, alternative data servers could be something worth discussing. If communication with the dedicated data server shows any problems, it would be nice to be able to simply switch to another one.

That’s it for now.

Happy Coding,
Manuel

Share/Bookmark

Singletons for AS3

Manuel — Mon, 21 Jun 2010 09:15:17 +0000

Singletons the curse and blessing of many coding projects. Among other pitfalls, you’ll basically introduce a global variable in your system, making UnitTests much harder.

Why Singletons?

Despite the possible problems they can present, they are just so darn handy sometimes. If there is some part of your code that needs to be accessed from almost anywhere in the system (like the sound system, or a global error text console and such) there is hardly a better way to achieve that.

Alternatives?
A global messages system to communicate between objects can achieve the same effect. We used to make heavy use of such a system system. However, according to our experience, maintaining that system is fairly time consuming for it gets more and more complicated over time. Besides, if a messaging system allows queing, you’ll never really now where and why a message was sent because you loose the stacktrace. So, right know we are reducing the work-load done by the message system, handing it over to direct singletons access. By this, we increased debugability and clearity of data transfer. Besides, using singleton access is much faster than routing it through our messaging system.

How to Do It?
The web already offers a bunch of solutions (1). Most of them boil down to implement the singleton code over and over again in each singleton. We didn’t like that and tried to come up with a better solution. When we define a singleton it looks like that:


/**
* Accesing this class somewhere in the code looks like this:
* cSomeController.GetInstance().DoSomething();
*/

public class cSomeController extends cSingleton
{
    public static function GetInstance():cSomeController
    {
        return cSingleton.GetInstance(cSomeController);
    }

    public function DoSomething()
    {
        trace("Yes, I can.")
    }
}

That is much simpler than copying&pasting the complete singleton code over and over. The corresponsing cSingleton-class looks like that:


package rsengine.patterns
{
    import flash.utils.Dictionary;
    /**
    * Singleton base class
    */

    public class cSingleton
    {
        private static var m_instances:Dictionary = new Dictionary();
        private static var m_unlockConstructor:Boolean = false;            

        public function cSingleton()
        {
          if (m_unlockConstructor == false)

          throw Error("You cannot create an instance of a singleton."
          + "Use GetInstance instead!");
        }

    /**
    * Returns an instance of the specified class
    * @param _class class
    * @return instance of specified class
    */

    public static function GetInstance(_class:Class) : *
    {
      if (m_instances[_class] == null)
      {
        m_unlockConstructor = true;
        m_instances[_class] = new _class();
        m_unlockConstructor = false;
      }
      return m_instances[_class] ;
    }
  }
}

Our singleton implementation significantly reduced the amount of code you have to copy&paste compared to the other singleton implementations out there on the net. We do know that our implementation of GetInstance() is a little slower (because of the Dictionary look up). Since you shouldn’t have too many calls to the GetInstance method this is probably nothing to worry about too much. Nevertheless, you could cache the result of GetInstance() if you do need to access the singleton more than once (e.g. in a loop).

Have fun and happy coding
Manuel

AS3: Singletons, ActionScript 3 Singleton Redux, google

Share/Bookmark

Numeric Enumerations (Enums) for AS3

Manuel — Wed, 14 Apr 2010 09:11:51 +0000

Something I really missed in Actionscript 3 were enums. If you need ascending unique numeric ids ( e.g. for naming array indexes ), enums are your friend.

For our current project we programmed a messaging system. The system uses unique numeric ids for message types and message channels. The list of messages and channels grew over time and right now each list contains more than a hundred entries. In the beginning we did the numbering ourselves like that:



    public static const MSG_OPEN_WINDOW:int = 0;
    public static const MSG_CLOSE_WINDOW:int = 1;
    public static const MSG_REGISTER_TIMER:int = 2;
    // .. and so on

For code beauty we were always trying to group related message ids, which often meant to re-index dozens of entries if we inserted an id somewhere in between. This was a pain!

The net already has assembled quiet some wisdom about “fake enums ins as3″¹, which do fit different needs (like some have type safety) but unfortunately not ours. Most of them are String based, which is what we did not want. So after putting in some thought we came up with a solution that worked for us. Now we can define our enums like this:



    public static const MSG_OPEN_WINDOW:int = cEnum.Enum(0);
    public static const MSG_CLOSE_WINDOW:int = cEnum.inc;
    public static const MSG_REGISTER_TIMER:int = cEnum.inc;
    // .. and so on

Now, by using static methods and a static counter we can create an arbitrary amount of coherent numeric values, which comes in very handy from time to time! Re-indexing is in the past now!

We want to share our little enum class with the web, so here it comes:



public class cEnum
{
  private static var m_currentIncrement:int = 0;

  /**
   * Adds an enum value to the collection
   */

  public static function Enum(_v:int) : int
  {
    m_currentIncrement = _v;
    return m_currentIncrement;
  }

  /**
   * returns the next increment
   */

  public static function get inc():int
  {
    return ++m_currentIncrement;
  }
}

Bottom line, if you need a neat way to maintain a list of static coherent numeric entries while type safety is not a big issue … this is an fairly easy way to do it. May this help you out there as much as it helped us.

Have fun and happy coding
Manuel

¹ Further readings on AS3 enums can be found here: e.g. http://www.herrodius.com/blog/87,
http://scottbilas.com/blog/faking-enums-in-as3/
or http://blog.petermolgaard.com/2008/11/02/actionscript-3-enums/

Share/Bookmark

Effortless Text Localization

Thomas — Tue, 29 Sep 2009 14:32:24 +0000

Automatization of repeated work is one of the keys to productive development. Another is abstraction of common problems to allow concentration on project specific work. Localization is one of the problems you have in nearly every project, especially in iPhone projects. The iPhone SDK brings interesting solutions that abstract many parts of the localization process.

The tool ibtool, for example, extracts strings from an interface automatically. The strings are placed in a .strings file, a textfile with key/value pairs. To localize an interface, you have to translate .strings and merge the strings back into the interface again. Because you have individual interfaces for every localization, it’s possible to adjust widgets individually for each one.

genstrings is another tool inside the iPhone SDK. It extracts textIDs from the source code and write them into a .strings file. You may ask how the tool knows which texts need localization and which do not. The solution is the macro NSLocalizedString, which will be replaced by a .strings file lookup method by the preprocessor, but also searched for by the genstrings tool to create the files.

Both tools help you to create a localized application without paying much attention to localization itself. But you cannot expect the localization department to search for .strings files inside your project and create localized versions of them. Of course this would be possible, but not very convenient, because you have to migrate the translated texts back into the interfaces using ibtool. Another reason for us at Rough Sea is that we use a localization interface from our publisher. This interface is well known to the localization department and the content is placed in a centralized database on a server.

So we have the great tools from Apple that help us to separate texts from the project and we have the great tool from our publisher that handles the whole translation and reviewing process. Now we need something to tie those tools together, because we do not want to insert new texts from the .strings file into the publisher’s localization tool manually or vice versa. This glue tool has to execute the Apple tools, extract the texts from the .strings files and insert them into the publisher’s loca tool. On the other hand, it has to check for new localized texts from the publisher’s loca tool, build the required .strings files from the results and merge them back into the interfaces. Sounds quite easy, but of course there are some obstacles to get there. You have to handle other things, like the deletion of a text entry or changes to an already translated interface. So you have to know what has changed since the last update and stuff like that.

It turns out that you only have to integrate this glue tool into the build process of your build server. The tool will update the localization database whenever the code or the interface changes and it will update the localized versions when the database changes. As a coder you only need to remember to use the text macro around your text id. You don’t have to add this text id in a file or anything else. As you commit your changes, the build server will do this for you. As an interface designer it’s the same: just create your interfaces in the primary language and commit it. After the localization department finishes localizing those texts, they will be inserted into the localized versions automatically. Of course you have to make adjustments to the interface if there are loca bugs like labels that are to small to hold the translated text.

As you can see those localization tools are a big black box for coders, interface designers and translators. The coders only have to write code, the interface designers design interfaces and the translators translate texts. At the end there will be a localized product.

Share/Bookmark

Famous Movie Monsters – 4

Chris — Thu, 10 Sep 2009 13:13:50 +0000

Here you can see Stripe from the movie Gremlins. He is the second movie monster based on a suggestion from our blog readers. The original idea came from Benita:By clicking on the image you can see a bigger version with a short Tutorial on how the image was created.

Chris

Share/Bookmark

Random Map Generation

Manuel — Mon, 24 Aug 2009 14:47:09 +0000

Designing an appealing and huge game world from scratch will take even really fast designers a looooong time: valuable time that can be spent in better ways. This is where generated content comes in handy. With the push of a button a designer can create a whole world (oceans, land, forests, deserts, mountains, cities, … ) in an instant. So this is what we decided to do for our game … and here is how we got to the finish line:

On the bumpy road to an actual working map generator we decided to split all map generation tasks into small modules: heightmap generator, water generator, forest generator, desert generator, and so on. In the map-generator GUI the designer can put these modules into a task list and define the order in which they are executed. Each module also has parameters that affect the characteristics of the generated map. Even though it is supposed to be a random map generator it is especially important to have deterministic behavior. Consequently, each module that actually generates content has at least a “seed” parameter for the random number generator. With the same seed the generator will create the same results every time. Changing the seeds will create a different map.

In the little animation above you can see the output of some of the modules.

Heightmap Generator
At first we create a heightmap. We use Perlin noise since it is built into the AS3 BitmapData class and it is amazingly fast. In the beginning we experimented with our own implementation of the diamond-square algorithm, but it was way too slow.

Water Fill
In the next step we apply water to the world. We simply declare everything below a certain height level as being under water.

Mountains
By looking for local peaks we detect mountains and flag the areas accordingly.

Humidity Map
By defining a water contingent that grows over water and decreases over land we can flag dry and wet zones on the continents. To make things easier we define our whole world as a west-wind zone. The centers of most bigger continents will be dry (yellow), coast regions will be mostly humid (green) and continental areas lying east of a big stretch of water will be very humid (dark green).

Climate Zones
Next we define climate zones in the world: tropical areas, temperate zones and polar regions. With this information we can easily place polar caps in the world.

Forest Generator
Using the information from the climate zones and the humidity map makes it possible to place different types of forests into the world. Jungle (purple) will be found in the hot and wet regions around the equator, while coniferous forests will be found close to the polar caps.

Desert Generator
The desert generator also uses the information from the humidity map to detect dry regions and place desert areas into them.

Well, now you had a look at some of the modules in our map generator. They are not only capable of creating earth-like maps (like the small sample map above) but also completely different maps by changing the parameters: a lake landscape, a waste land, a desert or whatever our games may need. With this we are able to quickly create new game content of any size for the players to explore.

Cheers,
Manuel

Share/Bookmark

R&D goes iPhone

Thomas — Mon, 03 Aug 2009 07:56:41 +0000

Hello out there,

my name is Thomas and I am the first programmer in our new R&D department. Like most of the other guys here at Rough Sea, I’ve worked on games for consoles (Nintendo DS and Wii) and PC before. I’m very excited to develop sophisticated software that helps us to make state-of-the-art games. Of course this is only technically, but I’m pretty sure that Rafael and Jan will assure this for the design part too.

I assume you’ve read the headline already, so you know what the R&D department will work on in the coming months. We’ve decided to do some research on the iPhone, because we think the way you use the iPhone is almost the same as how you play a browsergame. You get your iPhone out of your pocket, use it for a few seconds and put it back again. You have nearly the same procedure with browsergames: you open your browsergame window/tab, change a few settings and go back to work.

So the first thing to do is getting your working environment running. The only legal way to do this is to buy a Mac. I’m not really happy about that, because I’m a Windows guy and there are some differences in using MacOS instead of Windows. Maybe Apple only invented the app store to sell some of their Macs to iPhone developers. Nevertheless after some adjustments the Mac became usable. The nextStep (pun indended) was the installation of the iPhone SDK and all the tools that belong to it. It’s quite easy to get from the installation of the SDK to the first Hello World on the simulator (especially if you compare this to console development).

We at Rough Sea use test driven development and continuous integration to assure that we always have a deliverable product at hand. Unit Tests are already integrated into the SDK and it was easy for Ole to set up a build server on a Mac Mini with hudson and the makefile-like shell tool xcodebuild. You don’t have a makefile: the tool just uses the settings of the project file to know how to build. Another thing is that you can add and change text macros for the XCode IDE. Text Macros are very useful to write code much faster. For example, you can add an alloc-init call [[class alloc] init] simply by typing the letter a and then escape. There are macros for if, for and while too. Because we have different coding guidelines than the apple guys, I had to change some of the macros. You find them in /Developer/Applications/Xcode.app/Contents/ PlugIns/TextMacros.xctxtmacro/Contents/ Resources. Copy the TextMacros.xctxtmacro folder to Library/Application Support/Developer/Shared/Xcode/Specifications in your home directory. Just open the *.xctxtmacro files with a text editor to change the macros. You can add your own file and project templates too. This is very nice, because you can set up a default project with many settings, like Unit Test Targets, already in place, and use this project to create new ones with only one click. To add a new project template, create the project the way you like it and copy the whole project folder to Library/Application Support/Developer/Shared/XCode/Project Templates/GROUP_NAME/PROJECT_NAME. For file templates you should just copy the File Templates folder from /Developer/Library/Xcode/ to Library/Application Support/Developer/Shared/XCode/ and change or add the files you like.

Next time I will write about Objective-C and libraries from the iPhone SDK like UIKit.

Share/Bookmark

Feel the groove

Joerg — Tue, 16 Jun 2009 12:10:20 +0000

Our server code can be built with one click. The build process does not take long. To be precise, the build server says “last build: 1 minute 38 seconds”. That’s cool. (And mainly it’s because the code is not that complex yet…)

But despite fast builds and because they are definitely going to get slower as the project progresses, we need the ability to change certain parts of the game logic with a minimum of work. So far this is mainly for the game designers, who want to be able to change some equations that influence the game’s balance. Defining stuff in config files that are read on server startup is nice, and we use this as well, but starting the server takes time, too. A better way is to be able to change game logic at run time. So a scripting language was the way to go.

We decided to use groovy. Now groovy is not a scripting language at all, but more or less an object-oriented programming language that can be used as a scripting language for Java. Groovy has some advantages over Java like e.g. dynamic typing.

Unlike in other scripting languages, the groovy code is not interpreted at runtime but compiled into java byte code. So don’t forget to automatically reload the scripting files every now and then to make sure that changes in the files are actually applied.

We haven’t yet decided whether to keep the scripting in the release version of the game or not, since implementing the logic in the code is surely better for the performance. People on the Internet tend to accuse groovy of weak performance in comparison to other scripting languages. But it is very pleasant for experimenting during development. If you don’t believe me, go ask our designers…

Share/Bookmark

Common project management mistakes: Estimating tasks (part 2)

Joe Cool — Tue, 09 Jun 2009 14:19:46 +0000

Hi there,

we were quite busy over the last weeks, so updates of our blog are currently reduced. We are only going to post once a week in the upcoming month, but this should improve the quality.

Today I will continue my project management series. In my first post I described the common mistakes which are often happening when estimating tasks:

- Mistake 1: Estimation is not done by the task owner
- Mistake 2: The task has no proper description
- Mistake 3: Estimation is done by averaging worst case with best case scenarios
- Mistake 4: The tasks are too big
- Mistake 5: The tasks have unclear dependencies
- Mistake 6: The owner puts some unknown buffer time into the estimation

Please check out the first part of this article to find viable solutions to those mistakes.

The mistakes I wrote about are not really specific to a single department; most of them are quite common problems. Unfortunately, there is one department where task estimation can be very difficult. It’s obviously the programming department that I have in mind. Estimating tasks with programmers is quite an awkward business.

You need lots of knowledge and experience to get numbers that are even close to realistic. As a project manager you may wonder why this is so complicated and why programmers’ estimates are so often unreliable. There are several reasons:

Mistake 7:

Taking the estimates of a rookie programmer as the final estimate

Solution:
Programmer performance varies by a factor of 10, which means a very good programmer can solve a given problem ten times faster than a bad one/rookie. No problem, you think: just let the slowest programmer estimate the task. That will unfortunately not solve your problem.

Young programmers tend to overrate their skills and dramatically underestimate tasks. So let the lead programmers, who are able to rate programmer performance as well as task difficulty, review the rookie’s estimate. The more experienced programmers check the estimate, the better it gets.

Mistake 8:

The buffer time for the programming tasks is the same as for any other task in the project plan

Solution:
This is nothing new and a lot of people have written about this problem, but unfortunately it’s still not accepted as an unalterable fact. Maybe it’s because of the certainty that there is no simple formula to determine the right buffer time.

It really completely depends on your programming team. You might have a 100% or even 200% buffer time and it’s not enough. Track real life data and your estimates, compare them, learn from them . Every programmer has his own speed and estimation techniques. Find out which ones are reliable and which are not and adjust your buffers accordingly.

Mistake 9:

Assuming that a programmer programs 8 hours a day

Solution:
If a programmer tells you he needs one day for the task, does that mean one real life day? It depends, again, on the programmer, but you should not ask how many days; instead you should ask “how many hours do you need?”. This is very important because a rookie programmer might not have realized yet that his effective programming time is only 4 to 5 hours a day.

Mistake 10:

Changing numbers in the project plan in order to change reality

Solution:
Project managers very often reduce the (massive) programming buffer times after estimation is complete, because it tightens the project schedule and seems to save lots of money.

Well you know the answer already: this does NOT change reality and you will not save a single cent. Instead it will cost you a lot of money! Never reduce programming buffer times unless you are absolutely sure it can be done faster. To put programmers into a crunch because you reduced their necessary buffer times will damage your reputation, and the team will not trust you anymore and will sneak their own buffer times in their upcoming estimations.

Next time I will talk about crunch, a very common technique to waste money and lose good employees.

That’s it for today, thanks for your time .

Cheers,
Matthias

Share/Bookmark

Famous Movie Monsters – 3

Chris — Wed, 06 May 2009 13:02:32 +0000

Here you can see Chucky the first movie monster based on a suggestion from our blog reader Mr. Boomerang:By clicking on the image you can see a bigger version with a short Tutorial how the image was created.

Chris

Share/Bookmark

Famous Movie Monsters – 2

Chris — Tue, 28 Apr 2009 07:56:09 +0000

Last time I told you I already know what I will draw next for my new blog series Famous Movie Monsters. And here you can see one of my personal favorite movie monsters…By clicking on the image you can see a bigger version with a short MakingOf.
I already got some feedback and ideas for the next images in the series but if you still have a favorite you want to see write a comment to this post, name your movie monster and I will see what I can do…

Chris

Share/Bookmark

Famous Movie Monsters

Chris — Thu, 09 Apr 2009 15:13:03 +0000

I hope you didn’t take Manuels last blog post too serious.

Currently I’m working on a new series for the blog called Famous Movie Monsters. The series starts with Dracula (You know… the guy with the sharp teeth and sun allergy). By clicking on the image you can see a bigger version with a short MakingOf.
I know what to draw next, but if you have ideas, wishes, suggestions… feel free to add them in a comment to this post and who knows… maybe you can see your favorite movie monster here on our blog soon…

Best wishes and a happy easter!

Chris

Share/Bookmark

Discover the ground ! Discover the ocean !

Ole — Sun, 08 Feb 2009 17:28:40 +0000

Row row rock the boat … gently down the stream ….

And this streams leads to an ocean sooner or later .

Maybe it is time to discover the ocean. Google Earth 5.0 has been released and this gives you the opportunity to discover the ocean, the ground, the whole planet Earth.

Click Here for more information about Google Earth 5.0

Let’s play a game…

Chris — Thu, 15 Jan 2009 12:08:51 +0000

Take a look at the following image…

… and tell us which square is the dark one… square A or square B?
Easy isn’t it!? … and to show you your answer is the right one click
HERE!.

Chris

Share/Bookmark

Common project management mistakes: Estimating tasks (part1)

Matthias — Sun, 11 Jan 2009 22:53:59 +0000

Over the last several years I have managed and participated in different projects of different sizes. I made a lot of mistakes, some of them more than once. This time I want to talk about mistakes in estimating the time to complete tasks.

Estimating tasks is really tough work, and it’s done wrong most of the time. Estimations are never precise. I think that most project managers are aware of this problem, but may not know how to get better information out of their team.

Mistake 1:

The task is estimated by somebody who is not working on it — maybe by the lead, which is even worse.

Solution:
Tasks should be estimated by the owner of the task with the help of his colleagues or his lead. Programmers especially have different working speeds, which can be ranked from 1-10. This means a very good programmer can be 10 times faster than a very bad one.

Mistake 2:

The task has no proper description and/or is unclear to its owner.

Solution:
How do you know if the task has a proper description? Well, it’s a mixture of common sense and experience. If you, as a project manager, do not understand the task (e.g. it’s too technical), it might be already a very good hint. Tasks should be described non-technically, understandably and in only a few sentences. If you prefer working with user stories I would recommend to you this book from Mike Cohen.

Mistake 3:

The task is estimated with worst case and best case scenarios and the average is taken for the project plan.

Solution:
This doesn’t make sense because the owner has to make 2 estimations. In the worst case scenario there is probably a hidden buffer time, which is not obvious to the reader when checking the project plan. Ask only for one estimation from the owner or the team when estimating the tasks. It’s much clearer to them and they know you will add the buffer.

Mistake 4:

The task is too big and cannot properly estimated by its owner (tasks with 8- 16 hours are a maximum)

Solution:
As soon as a task is bigger than 2 days, it is time to break it down, because nobody can foresee the problems that are going to arise when approaching such a big issue. If you are not able to break down the task (e.g. because of a missing design), but you need the information desperately, you should estimate it and add at least a 100% buffer. Don’t forget to mark that task with “??”, to be sure to break it down later and re-estimate it.

Mistake 5:

The task has dependencies on other tasks that are not clear to its owner.

Solution:
This is not an easy problem. Try to make tasks as independent as possible when defining them. If you work with user stories, add the dependencies of the task to your war-room board and check if your priorities match the dependencies. It is really hard work for the designer and project manager to get this right. Communicate as much as possible with the team to avoid dependency hell early: it can vaporize your whole project plan if you do not care about it.

Mistake 6:

The owner puts some unknown buffer time into his estimation

Solution:
Again you need your soft skills and experience here to identify this problem. Some people just add buffer times to be sure they can handle the task. Be open with them, tell them that you will add enough buffer time, holiday and sickness absence. They will only tell you the right time if they trust you. Collect all the estimation data of each owner to get an idea of how well they estimate over the whole project.

I have some more mistakes on my list, but It is late already. So stay tuned for more in the upcoming days. Cheers for reading and I would love to hear your experiences…

Share/Bookmark