Saturday, September 22, 2012

Software project estimation: A little hands-on experience goes a long way

Earlier this month I attended a one-day Agile software development class at The Forge by Pillar in Ann Arbor.  A few of my teammates from work attended the class with me; the class ended up having around 25 attendees total, with maybe a third of those being developers.

On the morning of the class, we learned that as part of the activities of the day, we would be implementing a functional clone of a classic arcade game of our choice (Pac-Man, Space Invaders, Centipede, etc.), using a tool called Scratch, in 3 20-minute development sprints.

This initially struck me as aggressive -- a new game, complete with graphics, written starting from scratch, done in not a day, but in 60 minutes?  I suggested to my team that we do an implementation of Frogger, as that struck me as being relatively straightforward to implement.

The instructor then went on to ask if we had any "spikes" (unknowns that would merit taking time to do a proof-of-concept, if this were a real project) regarding the Scratch tool that we'd be using for development that he could answer for us prior to the first development sprint.  Not having been familiar with Scratch prior to taking this class, I found it difficult to come up with any questions more specific than "Um, what exactly is Scratch, and how does it work?"  (I did come up with some better questions such as "How does sprite collision detection work in Scratch?" but the point here is that it was hard to even ask questions about a framework that I wasn't familiar with.)

After writing up user stories (requirements) with my team, the class instructor did a quick demo of the Scratch tool; then, the first development sprint started, and I was able to get hands-on with the Scratch tool for the first time.  Within just the first couple of minutes of that first development sprint, I had a far better idea of what Scratch was, what it could do, and how long it would take to do things with it.  In short, Scratch allows you to set up sprites (characters, objects) on a playing field, and then manipulate them via a simple "drag-and-drop" event-driven programing framework.


This experience was striking as an illustration of the additional accuracy with which a project can be estimated, and how much better specific "unknowns" about an implementation can be identified, after there has been an opportunity for the development team to get some hands-on engagement on the project – particularly in projects involving a language or framework that is new to the development team prior to the project.


  1. I recently heard about Scratch, and it sounded interesting. Does it come with things you can use as parts and pieces in the game? (Like the frog, and the cars, etc.)

  2. Yep, a good variety of graphics/sprites -- including most of the things you see in the screenshot above -- comes with the framework. There's also a tool that comes with Scratch for quickly making your own sprite images, too -- I created each one of the two log sprites in that screen shot very quickly.


Non-spammers: Thanks for visiting! Please go ahead and leave a comment; I read them all!

Attention SPAMMERS: I review all comments before they get posted, and I REPORT 100% of spam comments to Google as spam! Why not avoid getting your account banned as quickly -- and save us both a little time -- by skipping this comment form and moving on to the next one on your list? Thanks, and I hope you have a great day!