Through a Mirror Dimly

I don't know what I am doing part of the time. That is a difficult thing for any engineer to admit, but it is true. The early days of any software project are filled with uncertainty. This is when you find out what is real and what is hype. This is when the development team really pushes back on the customer/marketing. The customer doesn't have to justify what they want, but they do have to understand it. I can't create an application that is "easy to use", "responsive", or "pleasant to look at". These are all requirements I have received in the past, but I cannot fulfill them. I can build an application that has buttons on the left that define the application steps, properties for the current tool/action in the lower center and help in the lower right. I can ensure that the user will get some type of feed back for every action in less than a quarter second. I can ensure that the widgets drawn on the screen have rounded corners and a 3D glass effect like those in Vista. The difference may see like trivia to some, but as an engineer the difference is huge. These differences are also important for QA and acceptance. The first set of requirements cannot be tested. The second set can.
So I find that most of the effort in the first few iterations of a project is actually spent prototyping and refining requirements. This is the time where Stories or Backlog Items are broken down because they were too general to begin with. This is the time when tasks are defined. This is the time when the original high level estimates are tested for sanity. This is also the time when the calendar is consulted to see if Joe UI Guru is going to be on vacation during the bulk of the UI prototype work. This is what used to be called design.
Now I know that we don't have a design phase anymore, but you gotta have a plan. I do agree that it does not need to be a thorough and detailed plan. Still one should identify the areas that represent the most risk. We are not going to spend time trying to figure out how we are going to put text on the screen for most apps. We know how to do that. In fact we know several ways to do that and that choice is an implementation detail. We are going to spend time on how the UI flow works to avoid the steps in the wrong order bug. Or we should. I believe the TDD, code and refactor approach assumes design is inherent in the act of coding and therefore assumes a pretty good, fairly experienced developer. If your team is made up of such people, then it will likely work because of there experience level. If you have say interns working on your team, forcing them to stop an think about the code they are about to create is probably worth while.
So what do we call this part of the development cycle? I like detailed planning.

Check back next week to hear how the story ends.