Cone of uncertainty

Why is estimating the effort necessary for a software development project so much more complicated than estimating the construction of a building? Because a software development project is a new project with mostly new people and often new technology for every new project.

Once again I had to experience that the estimation for a project was too optimistic. It is easy to estimate the expectable effort if yourself will be the person who has to realise the project. I remember that all estimations I did for myself where exact.

But as soon as the project is larger and is about a new business area, you have to do more work. You will have to do different kinds of estimations, for example a SCRUM story point estimation, a comparison with a similar project, a function point analysis and so on.

Now, there is the cone of uncertainty which tells us that an estimation done before the projects requirements were investigated properly could be far far away from the real effort you will spend. And the estimation will only come down to a more realistic value if you do another estimation after the requirements are clearer or even after you have started developing.

Amazon DynamoDB


DynamoDBNoSQL-Database is something quite new. I heard the first time about it a couple months ago and even read an interesting article about the topic which was in truth too complicated for me.

But recently I run into the question who a web shop like Amazon is storing its data. Surprisingly this is no secret and Amazon has published a description about their technology and you can even download an API to connect to the database and you can create your own DynamoDB on the Amazon cloud.

Here is a short summary about the concept in German. I had no time to translate it into English so far. Hope it is correct from a technical point of view!



We are working with SCRUM now for more than a year. But I did my first SCRUM training a couple of days ago. Was a very interesting training with a lot of nice people. I the three days duration of the training, it never got boored.

One picture was especially impressive: it shows the product backlog as an iceberg. The story is the following.

The product backlog consists of epics (very large user stories), user stories and grains of sand. It is not necessary to detail and estimate epics until they become part of the release backlog.

And it is not necessary to detail user stories into grains of sand until they become part of the sprint planning. This picture is very nice and easy to memorize. Thank you DasScrumTeam.