Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
November 1, 2014
arrowPress Releases
November 1, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Opinion: My Producer Hates Me
Opinion: My Producer Hates Me
May 23, 2011 | By Byron-Atkinson-Jones

May 23, 2011 | By Byron-Atkinson-Jones
More: Console/PC, Programming

[Xiotex Studios programmer Byron-Atkinson-Jones talks about how and why project scheduling problems can arise between coders and producers, in this #altdevblogaday-reprinted opinion piece.]

My producer hates me. No, it's true. He hates me because I am the only coder on the current project I am on, and he has to ask me every now and then how long something will take and I invariably can't answer him.

It's not as if I am a new coder; I've been coding commercially for something like 15 years, so what gives? I went to university to study Software Engineering, but I had actually been coding since the age of 12 (I'm now rapidly approaching 40) when I had the amazing Sinclair ZX81.

Okay, the code was nothing like it is now, but the point is that I am mostly a self-taught coder, and most of the time coding for me is just like driving a car -- I can do it without having to deeply think about it. I just get into the zone and out of the other side pop's code. This doesn't mean I don't plan code; on the contrary, I have sketchbooks full of designs for systems, but they are not formal designs in the sense of UML, Z, Yourdon or SSADM. They are more diaries.

The upshot is that I don't think of code in terms of systems, but rather I visualize what the end result looks like and start pumping out code until that end target is reached. Along the way I will create or reuse systems to help achieve that visualization, but I discover I need that along the road rather than pre-plan them. The closest analogy I can think of is when novelists say that the books almost write themselves.

I'm not going to claim that my approach to coding is great; in fact, when I look over old code, I ask what the hell I was thinking of, but with time, experience gets better and better as do my coding skills. And I practice hard. I code all the time. I just love making games.

It also causes issues at interviews when one interviewer called my attitude to coding "cavalier". I'm sure a lot of you will find my approach totally alien and possibly negative, and I'm not advocating it, simply saying that this is how I do it.

However, getting back to my producer and how he hates me. The issue here is that because of my free-running approach to coding, I don't know how long it's going to take because there is no definite plan. I prefer to list a set of features (the visualization), and then set a defined target date when those features have to be complete.

I then do whatever is necessary to hit that target. With experience not only came a more refined level of coding but also a back-catalogue of writing the same kind of code, so when I set target dates these days they are usually correct. If they are wrong, then I have learned another lesson and the next time I am in a similar situation I can be closer to the right answer.

Am I Alone?

Even though my approach doesn't lend itself to being able to specify how long a certain bit of code will take, I don't think that for some developers the situation is any different. Cliff Harris of Positech games once wrote this in a blog post: "When a coder tells you they don't know how long something will take they are not being obtuse, they really don't know."

There was also a conversation I heard when the coder told his lead coder: "Just pick a random number because that's all I'll be doing."

It would be interesting to one day do some kind of survey just to see how comfortable developers are about providing timescales.

What About The Poor Producers And Project Managers Out There?

In a fit of drunken madness, my boss once made me the producer of the company's main project. So, I've had the opportunity to see games from the dark side, and I can tell you they have it pretty tough too.

In fact, in an ironic way, they get asked exactly the same question as they ask us but on a higher level. They can only answer their question by asking us questions, and if we say we don't know, what are they to do?

What was really interesting in my time as a producer were the various reasons why I could not be given a time scale, some of which I used to give to my producer when he asked me.

I was in a meeting recently with three levels of authority present, with mine being the lowest. When the topmost were presented with the reality that game development is a hit and miss affair and we can't accurately schedule everything, their response was that that kind of answer doesn't help them plan a marketing strategy.

It's a stark reality that while as a developer I may prefer to live in my own bubble of code, I am in fact a part of a wider business plan. It's easy to lose sight of the fact that while I may enjoy making games, it is in the end a business and it's my job, not a hobby I am indulging in.

Okay, It's Bleak, But What Can We Do About It?

I can't even pretend to have all the answers to this or in fact that my solutions will apply in all cases. The creative nature of games means that as developers we are under a whole different set of stresses than a pure business led application. We are prone to subjective criticism that can have far reaching effects on the game and it's development.

If somebody in power plays the game and comes to the conclusion that it's not "fun", then that usually bubbles down to us workers on the front-line in the form of a command like "change the game to make it fun", which in turn has an impact on the schedule. Except, it can't because the end-date is an immovable object. Catch-22.

My personal opinion is to accept that, for the most part, attempting to schedule a game down to the smallest details is not likely to be a scientific process but an exercise in compromise. If you are going to approach individuals and try to elicit details from them, then approach them in a manner that is suitable for them.

I was speaking to a fellow developer from my days at Lionhead studios, Phillip Hounslow, about just this issue and this was his take on it: "Personally, I want my producer to listen and to believe in me as a senior programmer that my time estimates are as accurate as I make them. If they aren't what he wants to hear that's a different matter, but they are a point of negotiation, not a fact."

The comment about "if they aren't what he wants to hear" is a common one, and it's one that leads to unrealistic schedules. We've already covered that the producers and project managers have to report to their superiors about the schedule, but what happens if a coder gives an amount of time that the producer doesn't like?

I've heard responses like "we can't do that" or "we need to squeeze that down", and rather than actually try to deal with the issue, often the developer is pressured through guilt to give a value that is more palatable. I've seen instances where developers often drop their estimates by as much as 50 percent or greater.

This pleases the interrogator, but is it really an accurate estimation or a good way to go about getting an accurate estimation? To make matters worse, some developers will start by routine to give time values that they think the producer wants to hear.

The Practical Bit

I was serious above when I said I couldn't even pretend to have the answers to all these issues; I can only present how I cope. Ultimately it's up to you to find your own path and way of working. If you can, adapt to how your team works since that will be the path of least resistance.

Having said that, I'm a great believer in being who you are, being truthful in what you say and do, and above all be confident in that role. The moment I start to doubt myself, I find myself failing at what I do, panic sets in, and then I am no good to anyone.

The point is that I have to be confident enough to present a workable solution to the schedule that the producer can understand, and if they can't understand, then it's my job to pitch that solution to them because ultimately the alternative is to work ineffectively.

I feel uncomfortable supplying what I feel are inaccurate timescales, and when forced to break them down to fine-grained atomic tasks I always end up giving very pessimistic values. If the producer is aware of this, then they may be more inclined to work with me rather than try and force me into another model of working.

I am not trying to suggest this should be a one-way street; there has to be a measure of compromise on both sides. While I am educating them on how I work, I am also learning how they need facts presented, and if along the way I learn how to break down my high-level view into atomic tasks with timescales, then all the better.


All this is very idealistic, and the reality you are in may be that you don't have the luxury of being able to mould the way you present schedules. In this case, you have to cope the best way you can. These are some strategies I use in these situations

If you get surprised with an estimate for a task that you haven't seen before, then you can either give it your best guess or simply say that you need time to think about it.

If that fails and they insist you give them a number, then do what I do and point out that the number I am about to give is going to be a pessimistic worst case guess and can in no way be regarded as a realistic value. And if having heard that they are happy to continue then at the end of the day it's on their head. I usually go back with realistic value once I have given it some thought.

Monitor your progress throughout the task. Look at where you are and try to assess how close you think you are to the end. If it looks like you aren't going to make it, then communicate this fact as early as you can. Even though this information may not be well received, getting it in early means that something could be planned to help rather than blundering into the end and admitting that it's not ready.

Fight the temptation to be the hero and give values that you think management wants to hear. Ultimately, this will just end up with you being the enemy for having broken the schedule, or at worst you end up pulling stupid hours to try and compensate.

When you are considering a task, what in reality are you thinking about? Are you thinking about in terms of it being 100 percent complete, integrated, and tested? Or are you just thinking in terms of the task in isolation?

his may not be important, but it's one aspect that inexperienced developers often fall foul of and producers fail to properly specify: the task may not be just be about building a discrete system; it may also include the time it takes to get it fully integrated into the game. This one used to catch me out all the time.

Learn from those around you. I learned all I know from reading as much as I can and picking the brains of everybody around me. In that sense, I have an insatiable thirst for knowledge, but because of that, I also believe that I should be sharing what I learned. The more we share the better we get at this. Whenever I find somebody particularly good at scheduling, I grill him or her for as much information as I can.


I can't get away with talking about schedules without at least looking at the issue of crunch. I'm not going to lie, my particular way of working does lead me to having to do crunch, but that's my choice. As I get better and better at predicting how long I will take on a task, it happens less and less, but the things I can't predict are clients pulling deadlines forward or something in the design changes.

Those are facts of life, stuff happens. You could build contingency space into the schedule, but how much space do you allow? I've tried to get those managing projects I am on to build in redundancy, but it's a hard sell. Their reasoning is that instead of it actually being a buffer, the work will just naturally spread into it.

I have heard of some places that claim to have eliminated crunch, and even better than that, I have been in interviews where they go over the top to extol the virtues of their studio and that they don't do it, only to accept the job and within a week of being there find myself having to do crunch to cope with a task who's fate was decided long before I joined the company.

I am sure that there are places that genuinely don't do crunch, and I would love to hear how they do it. How do they cope with change? Do they build it into the schedule to begin with?

Unless you get some kind of pleasure from crunch (it does happen), then it's in your best interest to try and avoid it, and to do that we need to schedule better. Good luck.

[This piece was reprinted from #AltDevBlogADay, a shared blog initiative started by @mike_acton devoted to giving game developers of all disciplines a place to motivate each other to write regularly about their personal game development passions.]

Related Jobs

Twisted Pixel Games
Twisted Pixel Games — Austin, Texas, United States

Senior Graphics and Systems Engineer
Twisted Pixel Games
Twisted Pixel Games — Austin, Texas, United States

Mid-level Tools and Systems Engineer
Sega Networks Inc.
Sega Networks Inc. — Madison, Wisconsin, United States

Mobile Game Engineer
Forio — San Francisco, California, United States

Web Application Developer Team Lead


Jean-Michel Vilain
profile image
I believe you've spent most of your time coding solo or in very small teams. It's my case and I can recognize my way of working when reading your article. I have diaries full of schemes and texts about the non trivial parts of the architecture, but I avoid UML and co. I also have task lists, and sometimes I have to scrum.

Being able to predict how many days a task is going to take is all about experience I think. If you have to code stuffs you're not used to, how can you guess? Programming is easy. Programming unusual stuffs is not.

But the process you describe is very natural and is probably followed by many of us. I think we would enjoy coding in the same team :-)

Anyway, good luck!

Byron AtkinsonJones
profile image
I must admit I prefer small teams and when it comes to choosing where to work next my preference does sway it that way. Having said that I have worked in some pretty massive teams in terms of being on of the team and leading them.

As for guessing, yeah, it's hard to do which is where the thinking about components comes into it, if you can break a task down into smaller chunks and those chunks are similar to things you have done before then you can begin to build a picture of how long something will take. It's the non-tracking stuff that kills, being asked to just do 'this quick change' or 'just try this out for us'. I like doing them but they do still affect the schedule and are often forgotten about when it comes to answer for why something is late.

Ernest Adams
profile image
Knowing how long something will take to code is like knowing when you'll find a repeating decimal in long division. If you divide 3572 by 9354, how long before you find the repeating decimal? There's no way to know until you try it. Problem-solving is inherently uncertain. This is why shovelware was invented. :)

Jon Brown
profile image
You saved me from saying it. And don't get me wrong, some shovelware is reasonably good value, it's just not very exciting.

profile image
I have extreme respect for people that code. I don't do it professionally for others but I do learn things on my own. I have spent many late hours into the morning solving code problems on my own just because I wanted something to work. I didn't just want it to work though, I wanted to understand why it worked.

It's good when you can have a small team to work with I would guess, but I know there are super coders that love solitude for solving problems.

Pieterjan Spoelders
profile image
Good article.. in the 1 and a half years I've coded for a living I always find myself being too 'optimistic'. However, it's legacy code I'm dealing with and while I assume a lot of the time that everything I need is kind of there in the framework already.. it mostly isn't :) And then there are the 100 things you haven't even thought of, until you reach that part of your design.. setting and keeping a schedule is the hardest part about this job, I'd dare say :)

Tynan Sylvester
profile image
"So Thomas... can I have a schedule estimate on that 'lightbulb' thing you're working on? What? Well that doesn't help me plan a marketing strategy."

I wonder if we'll ever have a broader understanding of how game design is actually about inventing knowledge and handling unknowns, not manufacturing an object. It's going to take a long time and some evangelizing, but I have hope.

Jeffrey Crenshaw
profile image
I'm with you :(. I wish I knew what I could do to speed this up, but I am just a loud mouth with very few ears listening.

Mark Harris
profile image
Invention is a subset, paid for by the mass market. You don't normally have one without the other. There needs to be a source of survival for any individual or group invention.

It all stems from the earliest days, if one person is going to fiddle around all day trying to find a way to grow more food with less work, then someone is already out there growing enough food for himself and the inventor.

You need to appreciate both sides, and if you're going to invent you need to balance it with some sort of resource gathering.

Jeffrey Crenshaw
profile image
From a high-level societal performance perspective, burning people out with absurd schedules to keep up with the competition that's willing to do the same is not efficient. I agree that cooperation is needed, but you can not have proper cooperation in a hierarchy filled with fear because the powerful few can decide who gets to put food on the table this winter. If these powerful few were somehow ethically evolved from the rest of us -- say the equivalent of a mature adult to a room full of kindergarteners -- I might have more faith in them. But my experiences show otherwise; they are at best at our level, and at worst psychopaths whose psychopathic nature earned them their position. (I just got through reading this:, an oldie-but-goody inside look at EA during the ea_spouse era, it's sad and not uncommon in our industry or others).

Well, let me reiterate that I agree with your sentiment -- the inventor and the mass market is needed; the artists and the audience. And since large works of art are complicated, they need to be managed, and budgets need to kept in-line. But we idolize the budget keepers and put them in positions of power rivaling those of Egyptian pharaohs, when they are really no more than middle men. I just don't believe the middle men are needed, and certainly not enough to be getting paid ten (100?) times what we "lowly inventors" earn. No, those in power take advantage of our structural needs (which you described in your first paragraph) to form a type of emergent slavery that most people don't see due to its complexity. Utterly depressing, utterly disgusting.

In the earliest days, if one person got orders of magnitude more food than the effort they put in, how many people would end up starving to balance it out? It's neither side in this equation that's the problem, it's the ugly ugly middle.

Mark Harris
profile image
There is, as always, a tendency to veer toward extremes. As you say, one bad egg in a position of influence/control can throw off the entire equilibrium.

We see time and again that the most successful endeavors over long periods of time are those that can maintain the balance between the inventor and supporter, to use our analogous terms. Current successes are used to fuel future inventions.

There will be no end of hierarchical systems, I'm afraid. While those systems mainly serve their purpose of adding a layer of organizational control over the increasing complexity of the system, they are as susceptible to corruption as any other.

As with any position of authority or influence, it is the quality of person that makes the difference, steering the system toward efficient and relatively stable production or toward the de facto slavery you mention.

Fortunately inferior management usually leads to the eventual destruction of the entire system, thereby releasing the resources... unfortunately this also can take a pretty long time in very large organizations, or forever in monopolistic/dualistic situations.

The disenfranchised who escape these systems tend to be those who start their own, to do it in a better way, and the entrepreneurial cycle begins again. Hence the indie movement making use of new technology to break the monotony of the corporate software culture. Many of these indies have, however, gathered their resources and training from the same pool of mass market corporate software that they wished to escape from in the first place.

A complex problem worthy of debate and study. I appreciate the parley.

Sebastian Cardoso
profile image
Good read!

Glenn Storm
profile image
I love this opinion article. Thanks, Byron.

"Am I Alone?": no, the process you're describing sounds like Agile, and the many flavors of it. The situation you're describing is a common clash between this methodology and other, older, more business-friendly methods, like Waterfall. And your take on how to handle through adaptation, respect and (above-all) communication, is golden. Cheers!

Further: your worry about not conforming to strict engineering standards, like being able to accurately predict development time, reminds me of this great Chris Aitchison blog post, recently brought to my attention by Carlo Delallana :

Jerry Pritchard
profile image
This just all goes back to the basic act of communication. If someone asks your opinion or what you think of something, don't just shrug your shoulders and say you don't know. Same thing applies when management wants to know something that you may not know yourself, give them an educated guess and get back to work. If it becomes a repetitive habit of management constantly asking for updates or reports, kindly explain to them the work is going to take longer to complete if they keep distracting you, followed by another rough estimate.

Producers don't need specific details or numbers, they'll fluff or pad the numbers anyway, so it doesn't matter.

Jeffrey Crenshaw
profile image
I don't think I want to dismiss scheduling in its entirety, but from my experience it is often the case that the duration of the schedule is set before the tasks are planned out, sometimes even before the design is finished. And it's never long enough. How can we avoid crunch if, instead of being asked how long things are going to take, we're told how long it must take and asked to robotically output time estimates that fit into that predefined slot. At that point, you're not being asked for your expert opinion or given a chance to set things straight, you're just doing a little dance that lets middle management toss the blame at you for something beyond your control when the schedule slips. You're a scapegoat. A stress ball. I don't know, I can't be the only one that's gone through this :P

Another thing I've been thinking about lately. If you guess a task is going to take a day and you work twice as fast as you expected, you only get half a day back. But if you guess a task is going to take a day and you work twice as slow, you lose a full day. Another way of thinking about it: The best you can do is finish the task instantly and get the full day back that you scheduled, but there is no limit on how long it can take if unexpected problems keep cropping up :/. I've experienced this with working super fast on several small tasks to get a few days ahead, then falling behind again because of one or two monster problems that end up harder than they seemed.

I really and truly believe that working without a schedule (and with marketing & business as aids, not as overlords) but with a general agreement that the game needs to get done will produce the best result and keep workers happy and make the most money, but I don't know how to convince anyone of power of this. I don't know, it's like - how do you convince a profit-chasing suit how to properly touch people's hearts with games? Or that they should even care to try? How do you convince a dictator that a democracy is more "right" when the dictator is making off well under their own rule? How do you convince a psychopath that murder is wrong if they just... just don't agree? Everyone's just as stubborn as everyone else with whatever opinions they've embedded into their psyches, it just comes down to going back and forth trying to justify your opinion with faux rationale, then the person with power eventually winning anyway. It's all a sad little dance to the background beat of an amoral universe.

Good article btw :).

Mark Harris
profile image
Everyone has their pressures, from the janitor up through the board of directors. Those pressures are often pushing/pulling in different directions.

The mark of a good business is to balance the interaction of forces such that you reach some sort of equilibrium. Needless to say this is exceptionally hard to do. How often, really, do two individuals completely agree on something, let alone two hundred?

It's a constant battle to keep chaos at bay, and up and down the chain we're all (hopefully) just doing our best to create the best products we can. We don't always succeed, unfortunately.

Trust me, though, the suit at the top isn't worried about the money just to sate some evil desire for cruelty or to crush your creative dreams. He is worried about the money so you don't have to be, and even he answers to his shareholders (or his bottom line in a private company).

Jeffrey Crenshaw
profile image
"He is worried about the money so you don't have to be"

No he isn't. I wouldn't have been laid off twice as cost-cutting measures if anyone in power in this industry gave a fuck about me (and in case anyone is rightfully wondering, I did a damn good job both times and worked crunch hours with everyone else and got good reviews, so I know it's not performance). And it shouldn't come as news to anyone that I'm not alone in unjust layoffs. Thanks for your reply, but it just isn't true.

Our purposes in life aren't to create "Good business" or "products", they are to bring joy to the world through the artform that we have studied and fallen in love with. Business is just a means of doing that, but it has somehow become an idol, an end of its own. Oh, but what to do about it...

Mark Harris
profile image
Business is merely the name given to the act of trading work for other resources. You are trading the results of your work for the results of another person's work.

Honestly, layoffs are unfair, but sometimes necessary. Layoffs happen precisely because someone is watching the money, and the future money, very carefully. At times layoffs are the by-product of some a-hole trying to make his mark by cutting costs, but most of the time they are made to re-structure the business so that it is sustainable. The worst thing about layoffs is exactly what you said, they have nothing at all to do with performance. You work your ass off, do a great job, and somehow still you're out of a job. It's crazy frustrating and unfair, and I truly understand that.

However, think of it this way. Company A has 5,000 employees and brings in X revenue. There are some problems, be it the fault of the company or the environment, and now revenue is X-20%. The company is now losing money. There is negative profit. If you're in charge of the company, do you decide to support all 5,000 employees until the company goes bankrupt and all 5,000 are out of work, or do you layoff 1,000 so that the company remains sustainable and 4,000 can keep their jobs?

That's obviously an overly simplistic view that doesn't account for a multitude of other factors, but the point remains. Sometimes layoffs are necessary to keep a business solvent, and very few people feel good about it.

For a good portion of people the purpose in life is survival, and if we get lucky enough to survive or even thrive doing something we enjoy, well that is a sweet sweet deal. Most of us aren't in that position, though.

Andy Satterthwaite
profile image
As a producer who used to be a coder (many, many years ago) I find it surprising that your producer hates you.

If, as you say, you can work to a required delivery date (and you get it done by that time regardless) then that sounds perfect.

Estimates of individual tasks are almost meaningless in terms of scheduling because it is so hard to specify what that task is - they almost always balloon out because of unknown issues, design creep etc.

However if you can say we need to have Feature X working in game by Date Y ... and that happens, then the project can be planned.

If your producer still hates you that much, you should come and work with me instead.

Deborah Marshall
profile image
Just curious for anyone who's worked as a developer both in games and in another field (such as business enterprise software, just to name one): is there a significant difference between project scheduling in these industries? Does the nature of gaming make it more difficult to produce software than in other fields, or are the challenges the same?

The reason I ask is that I have developer relatives who work for HP, Microsoft (not in games), and other big software companies. They have crunch too, but they either 1) don't talk about it as much or 2) don't have as much of it (I honestly don't know which it is).

Mark Harris
profile image
The artistic and experimental nature of games, combined with their abstract goal of being "fun" makes them much more difficult to plan than some other software. Especially if you're using traditional project management paradigms such as Waterfall.

In business you get a feature set, normally with concrete specifications. We need a website that provides X functionality, presents X information, etc. However, outside of the standard inaccuracies and feature creep you don't have that subjective extra step, it doesn't need to be "fun". It doesn't have to have that intangible something that makes people play until 4 am for a week straight because they just can't get enough.

When you combine software development with an entertainment product you increase the complexity of the planning and risk mitigation process exponentially.

So yes, it's harder. :)

Judy Tyrer
profile image
This is one of the biggest myth of game development I know and I am really hoping someone at Myth Busters will take it on. Yes, prototyping is hit or miss, but prototyping is only one tiny part of game development and there is no reason that the rest of the software developed (the engine, AI, game play) cannot be done so with the same processes that have served the computer industry well for over 50 years.

Work out the "fun" in your prototype, NOT in your game engine. Engineer your game engine like you engineer operating systems, IDEs, device drivers, and every other piece of software. Then port the "fun" you developed in your hack and slash prototype to the well engineered software. You might be surprised how well that works.

And then, of course, hire a QA team we have respect for, treat QA as a career choice and not a foot in the door to do something "real", and by gosh, we might just turn this whole industry around.

*steps down from her soap box*

Mark Harris
profile image
Yep, it's just that easy.

Deborah Marshall
profile image
Thanks for the insights and opinions. I think there's truth in both statements. One other variable I think adds to the entire mess is that the average game developer is younger than the average business software engineer. I've worked for three different game studios now, and the average age is between 26-30, while my relatives work at places where the average industry age is in the higher 30s to late 40s. Experience must make some sort of impact on this process.

Buck Hammerstein
profile image
good article.

in any industry the rule is " under-promise and over-deliver" so lean toward the worst case scenario in the time line and surprise everyone when it's done early. i like how you described the producer's side of the equation. project management can be the worst position to be in when it comes to meeting goals... you're just stuck not doing much to get there but you have to figure out what is needed to reach the end.

great read and look forward to more of your features.

Joe McGinn
profile image
An idea from the agile technique of scrum that may work for you: assign points to tasks, not estimates.

What are points? An arbitrary relative scale. What you do is rank every task on an arbitrary, relative scale, based on your gut feel of how big the task is. Do it at a fairly high feature-based level - so your game might have 40 or 50 pieces to rank at most:

0, , 1, 2, 3, 5, 8, 13, 20, 40, 100

Then you measure how many "points" you can do in a week. Do it four or five times and you have your personal velocity in points. You will find this much more accurate that traditional time estimates.

Why should this be? Simple: people are BAD at giving absolute time estimates. There are countless studies proving this is so. However, it's also been found that people are very GOOD at relative estimates - ranking the relative complexity of tasks. With your level of experience, you are probably great at it.

Try it. You'll like it.

Nathan Frost
profile image
Joe, I've found the Scrum approach you reference to produce far more accurate task estimates than just guessing. I wish I'd used this kind of empirical estimation for every project I've ever worked on!

It's sometimes been challenging to get others to accept that these "abstract points" make more solid schedules before they've tried it, but I hope that the industry standard of "wild guess" estimates will be replaced with empirical estimation methodologies as demonstrable results accrue.

Achilles de Flandres
profile image
good read!