Search

Monday, July 14, 2014

The Futility of Art Estimation

Artists frequently are often frustrated when asked to estimate how much time a new piece of content will take to build. The problem in asking for time estimates for art is that quality is the large variable in the equation that cannot be fully factored in until something is actually built first.

Unlike code, which has more of a binary definition of done, art has a larger subjective quality variable that frustrates any attempt to assign time to it’s completion. What we should be doing is negotiating the quality and observing the time it takes to achieve that quality. 

I’ve coached teams to focus on quality and explore the time it takes to achieve it in a piece of art through time-boxing.

So instead of saying: “Tell me how long it will take to finish this asset”. We are saying:  “Let’s spend a week of time to finish something and see what the result is.”

The variable goes from time to quality.  We'll get one of three "goldilocks" results:

  • The quality is too low.  The time-box is too small. 
  • The quality is too high.  The time-box is too big. (we've all seen 10,000 polygon fire hydrants! ;) 
  • The quality is just right.  The time-box is probably a little too big, but it's close. 

A time-box is a negotiation between the product owner and the artists creating the asset. It’s not picked out of a hat. Often, the conversation about the duration of the time-box is very revealing and informative to all those involved.

As artists and teams learn more about the quality/performance bar being established (and translate from pre-production to production of more similar content), the time-boxes become more of a reference to forecast completion dates. Teams will continue explore ways of shrinking those time-boxes through improved practices and tools.

4 comments:

Clinton Keith said...

Greg,

I agree that I wouldn't commission art from an experienced independent artists using time-boxing. However, this blog, Agile Game Development, is focused on topics of game development, not that. It doesn't compare to the exploration (quality, budget and schedule) that game artists face in preproduction.

It's interesting that you reference Michelangelo though (btw, his name is not "Michael Angelo"). The price he bid for the Sistine Chapel was *way* off due to the fact that he had never painted fresco before and that the scope bloated. He should have iterated on a few fresco paintings, to explore duration, quality and scope with the Vatican and then perhaps used a better way of coming up with an estimate for the total instead of "guessing" up front.

In video games, we explore then we construct. Early fixed estimation without knowledge leads to long term problems. Problems such as those that you see on your program and my former program, the F-35. The F-35 is an unmitigated disaster, much of it due to the limitation that the government puts on contractors for up-front estimation. Early exploration would have discovered the weight issues, the lie that "jointness" saved money and the cost of the political decision of the B version.

I realize you are waging a social media campaign to fight the forces for exploring alternatives to estimation and nothing I've said will convince you otherwise, but you add value in keeping us honest.

Glen Alleman said...

The Michael Angelo is a weak attempt at humor.
Bt my name is not Greg

Clinton Keith said...

Autocorrect prefers Greg ;)

Tim said...

I just wanted to post to say that was an awesome exchange between you two. Also, thanks for the post.