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.