Relative Estimation

Relative Estimation

One of the first things anyone with a stake in a software development project wants to know is “When will I get it?” The trouble is, people are pretty bad at estimating. The concept of relative estimation came about as a way to try to allow for a better estimation model, as well as to decouple the basic question of “When?” from the developers mind. Instead, the developers are asked to estimate sizing using something called “Planning Poker” and any one of a number of different “measures” of the complexity and difficulty of a given user story that they may be working on. I typically use Fibonacci numbers on my projects.

The point of estimation is that the number the team comes up with during the planning poker session (called “Story Points”) is purely thought of by them in terms of the complexity and ease/difficulty of developing what is being asked of them. NOT tying it to any false notion of how long it is expected to take by the client, stakeholder, management, whatever. If you can get your developers to do this and above all to be CONSISTENT in their application of their own definition of complexity, the rest falls into place. This is one of the key difficulties of agile, particularly when a new manager comes in and doesn’t understand the concept of relative estimation. Starts putting pressure onto developers to change their estimates of stories, trying to get them to commit to timelines for delivery etc. Of course this then breaks the entire process and you’ll very quickly find that you start delivering likely behind schedule again.

This is because one of the key aspects of Agile or Scrum based development is the concept of Velocity, which is a measure of how many story point a team works through in a given sprint (work period).

If your sprint length is 2 weeks and you can see that over a given period of time your development team typically burns through 20 story points per sprint and your backlog consists of user stories (requirements) which have been estimated at 300 story points, you can be pretty confident that it’s going to take about 15 sprints (or 30 weeks) for your team to work its way through the rest of the backlog.

The concept of relative estimation is so important because it’s one of the key things that takes away the human inability to calculate all tasks involved when working out a timeline.

It’s also very important in relation to our examination of Star Citizen. Certain people (whom shall remain nameless!) try to make a big song and dance about how:

“Star Citizen has been in development for 4 years because they said they started a year before the kickstarter!”

And even if this was the case, it’s pretty irrelevant, even if you estimate projects in terms of man days rather than story points. Why? Well quite simply, Story Points are a way of figuring out the man day run rate based on observable performance rather than less accurate forward projection trying to account for all variables. But either way, ultimately a project is still measured in terms of a currency unit cost and this is represented by man (or person) days. Why is this important? Well, it should be pretty obvious by now. But just in case a certain someone is reading this article, I’ll spell it out for them:

THE AMOUNT OF MAN DAYS OF DEVELOPMENT 8 PEOPLE CAN DO IN A YEAR IS (IF SCALED LINEARLY) 3.2% OF WHAT 250 PEOPLE CAN DO IN A YEAR!

What this means of course is that as CIG have grown, their development efforts have scaled up (although as we know from earlier, not in a 1:1 fashion as it does when going from zero to one developers). I don’t know how many people CIG have hired and in what capacity when, but it’s pretty likely that if you took the entire code base as it exists now, you may find that those original few people who were coding in the first year would have created a tiny portion of the overall code base as it exists now. Simple example:

Project “MakeGameXYZ”

Year 1: 1 developer. Work accomplished? 1 man year.

Year 2: 2 developers. Work accomplished? 2 man years (keeping the example simple, but remember in the real world, output is likely to be less than 200% of what 1 developer produced!).

Year 3: 5 developers. Work accomplished? 5 man years.

Year 4: 10 developers. Work accomplished? 10 man years.

How many man years of development have been accomplished in total? 1+2+5+10 gives 22 man years. Your first developer who started things managed to do a meagre 4.5% of the total group output in that first year.

So yes, of course CIG did some work before the Kickstarter started. How much of the overall project does that represent? In all likelihood, virtually nothing in code as it stands today. Arguing they should be done by now because they’ve worked on it for 4 years is just complete ridiculousness. What should be looked at is how much time in man years is taken to develop your average AAA online game, because that is what CIG are doing with Star Citizen.

Follow Wccftech on Google to get more of our news coverage in your feeds.