Think about this for a minute, say your Noah, walking down the street, minding your own business, and a big voice booms out "Noah, I want you to build an Ark. When can you ship?" Here's the proper response -- "Right, what's an Ark?" When the big voice says "it shall be 200 cubits by 40 cubits by 60 cubits" you respond with "Right, what's a cubit?" And so on and so forth. The point being that you cannot give an accurate estimate without a detailed understanding of the tasks involved to carry out the development work. I don't think you can efficiently develop a "complete" list of developer tasks upfront, but you've got to get deeper than "build an ark" in release planning. "Build the rudder" and "create the keel" and "attach the ramp" are much more actionable user stories.
My project has run into some difficulty in project and story management (in no small part because *I'm* sharing a bit of the pm hat). Specifically, we as an entire organization, missed a lot of complexity and fine grained detail in going from a traditional functional and technical specification document to detailed user stories and tasks. The warning sign that I (and everyone else) missed was vague, amorphous story titles like "Create a New Invoice" and estimating that story in release level planning. That simple "Create New Invoice" CRUD screen has turned into a myriad of user defaults, cascading dropdown lists, about a dozen new fields, and a fair amount of branching logic because there is at least four different logical types of "Invoices."
I made a conscious choice early on in the project that we would move into coding as quickly as possible because I felt that it was more important to build up momentum early than run into analysis paralysis by trying to get the story list perfect upfront. I knew that our user stories were vague and that there would be plenty of new stories spill out as we got an iteration or two into the project.
What to Do?
- Assume that your first estimate sucks and revisit it as you go. Revise estimates early on as you learn more about the problem domain in the first iterations. You always discover new stories as a result of early development. Update the story backlog and communicate those changes to your management and customer as early as possible.
- Every development task or need should be represented by a story card that is visible to the team and management. My current client depends on developers "knowing" how to interpret requirements and apply them to their user interface. That domain knowledge by their developers is a great thing, but those implicitly understood tasks have to be expressed explicitly in story backlogs so that the project can be accurately sized and controlled. My team is all new to their organization and the dependency on implicit tasks has got us into trouble with our initial release planning. In retrospect, we should have pushed harder upfront to understand the details
- Get a "Domain Expert" on, or very readily available, to the development team. Specifically, a domain expert who has a vested interest in your project succeeding. I think this rule applies to any type of process or team. The only difference compared to waterfall techniques is that iterative or Agile projects admit that fact. The most successful project that I've ever been a part of had the business sponsor and team engaged on a daily basis (it wasn't an Agile project, it was the 20-something Jeremy works lots of hours process).
- In release planning, get the Business Analyst(s) to walk through candidate stories, out load, in detail (basically, do a lightweight JAD). Throwing a specification document over the wall to the downstream group and running away has to be the dumbest aspect of waterfall programming. Face to face communication conveys much, much more information than spec documents. I remember now how utterly moronic waterfall thinking can be. Your project stands a much better chance of success if the developers, requirements folks, and testers interact on a daily basis and pull together for a common goal.
- Write acceptance tests early in iterations. We've found a lot of requirement needs by writing detailed acceptance tests with Fitnesse because it flushes out a lot of technical detail that isn't apparent at the "spec" level.
The same problem exists for software designs, especially upfront design specifications. I've seen too many teams create design specifications with no more detail than a single UML component diagram with a box for "the Invoice component" and an arrow pointing to the "shipping system." I'm extremely dubious about the value of doing a *lot* of UML modeling upfront before coding, but it's even more ludicrous to say "we've got a design" in a waterfall shop just to check off a process step when you really don't know much of anything.
Geek points for whoever tells me what the title of this post is from. Hint, he used to be really, really funny before the goofy rainbow colored sweater era.