Pre-Development Planning and Architecture

Jeff Storey

Ranch Hand

Posts: 230

posted 9 years ago

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?

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.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

Jeff Storey

Ranch Hand

Posts: 230

posted 9 years ago

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.

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.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

Jeff Storey

Ranch Hand

Posts: 230

posted 9 years ago

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.

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

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus

Jeff Storey

Ranch Hand

Posts: 230

posted 9 years ago

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 ]