Pre-Development Planning and Architecture

[Jeff Storey]

When starting a new agile project, typically how much time should be spent up front doing things like developing a high level software architecture (i.e. push vs pull system) and creating the first pass of the product backlog? Is this appropriate to do during the first iteration of a project? Or should other time be set aside for that?

Thanks,
Jeff
[ March 02, 2008: Message edited by: Jeff Storey ]

[Ilja Preuss]

Originally posted by Jeff Storey:
When starting a new agile project, typically how much time should be spent up front doing things like developing a high level software architecture (i.e. push vs pull system)

Just enough to roughly estimate the product backlog.

and creating the first pass of the product backlog? Is this appropriate to do during the first iteration of a project? Or should other time be set aside for that?

That, of course, depends on the size of the project. I don't know the "official Scrum answer", but if I remember correctly, "Planning Extreme Programming" suggests that it could take anything between a few hours and a week.

Typically this should be done before the first iteration starts.

[Jeff Storey]

Sounds about right. But, should a new project try to do extensive requirements gathering/analysis before the project begins? I understand the concept of doing the least amount required so change is less difficult, but if we don't know the details of what we're building, how do we know what to build? Similarly, if we only make a product backlog big enough to get us through the first iteration, how can we begin to estimate a project's duration (or will the backlog be finished soon there after)? Thanks.

[Ilja Preuss]

Originally posted by Jeff Storey:
But, should a new project try to do extensive requirements gathering/analysis before the project begins?

Depends on what you mean by "extensive". In general, your first plan should be wide, but not deep. That is, gather as many requirements as possible, but don't analyze them in depth. You want just enough details so that the developers can give very rough estimates and the customer can prioritize them and select them for iterations.

Mike Cohn's book "Agile Estimating and Planning" is considered the seminal book on this topic.

[Jeff Storey]

Ilja,

Thanks for that response. I'm actually currently reading that book (almost finished too). I like to get other points of view too and you've really helped with that.

Thanks,
Jeff

[Ilja Preuss]

Frankly, I haven't yet read that book. So, does it look like I'm disagreeing with that Mike writes?

[Jeff Storey]

He doesn't get into the details of some specific amount of time spent up front doing requirements analysis, since it is going to vary with the scope of the project. I think the general idea is to do enough analysis (and product backlog development) to at least get a rough scope the project, which would go along with your thoughts of wide but not deep. Since agile is so welcoming of change, there is no sense in trying to develop a very detailed set of requirements up front since you're probably wasting a lot of time.

One thing that a lot of software books really stress is that the quality of the product with respect to the customer's expectations is really the most important thing. Sure, it might be a little late, but most customers would probably rather have late and right than on time and not so right. So, make a rough estimate up front, refine it as you go along, but just keep the customer in the loop so there are no big surprises at the end.
[ March 05, 2008: Message edited by: Jeff Storey ]

[Scott Ambler]

You might want to read my articles on initial requirements envisioning and initial architecture envisioning to get a handle on how much up-front modeling you might want to do.

- Scott