This post is more of a comment than a question. I'm hoping to engage a few, or a lot, of people in a discussion on the relationships of Area and Iterations.
One of my larger complaints about TFS is in the relationship of Areas and Iterations. Perhaps I think of them in the wrong mindset, in which case I need to bump up my reading on software development theories. I feel that Iterations need to come in two flavors- Team project level iterations and area iterations. I continually want to place a set of Iterations that can only apply to given Areas. This can be done but only through a non-trivial amount of modification to the process template and maintenance is then a nightmare if one creates new areas on the fly with new iterations subsets.
On the other hand, some iterations are project level and that’s exactly where they should live but other iterations have no context outside of a given area. This is how I see the proper Iteration/Area relationship.
Project----
|
Project Iteration (1...n) ----
|
Project Area (1...n) ----
|
Area Iteration (1...n)
Now I realize this a V1.0 product and these are exactly the type of features that if I were the lead or product manager would say – “Scope! Let’s see how the community uses it and we’ll slate that for future releases”. Then again, perhaps it’s not been a discussion because, well, it’s just wrong.
You tell me. What do you think
The relationships of Area and Iterations
Geoff Henry
Right. Iterations should not necessarily have to be 'contained' by an area.
The area breakdown is more of a product, area, feature and/or component break down and the iteration is more like a fix by. Bugs from different areas of the project can be fixed in the same iteration.
SolarScott
Based purely on a longtime dogfooder's POV, I'd say you're both partially right. On one hand, it's easy to separate the role Areas vs. Iterations play in our system: like Polo wrote, Areas are basically for grouping into features & subfeatures, while Iterations track progress over time.
Then again, I'd be lying if I said there weren't lots of widely-scoped Iterations in our team project that are only used by a small subset of feature teams -- teams which, admittedly, can usually be pinpointed as "the guys whose work items lie under Area X." That said, I think adding explicit scopes to these ideas within the TFS product would be adding complexity for complexity's sake far more often than it would gain in day-to-day usefulness. The Iterations in my team project that I never use don't both me, any more than the extra team projects in SCE do. In fact, I could argue much more convincingly for a way to hide the latter than the former, since team projects are more broadly scoped by design (i.e., the Xbox team project is much farther removed from my work than the TFS teams who happen to use Iterations I don't.)
jrcdude
For me,
I think the Area and Iteration is quiet obervious
I will treat Area as functional or component boundry
it stay as static aspect of software project.
then I will treat Iteration as dynamic(process) view .
so, put them all together:
a iteration would contain lot of area, and a area might base on the iteration to
slice into different version.
therefore I could easy to setup a roadmap base on the iteration and area.
Ideal of mine
Polo Lee
vodka
I think Richard has converted me to his line of thought. It would add complexity, no doubt and it's not a big deal to overlook the iterations and/or areas that do not apply to you as a user.
I think my more regimented desires come from too many experiences with poor process and poor enforcement of the processes that do exist. Just like with static code analysis I like it when I can help automatically enforce the rules especially when the data is used for reporting- Garbage in/Garbage Out.
I do tend to lean more to the cost of admin for the benefit of more tightly controlled user experience. Yes- that's not very agile I know. :-) And can see how this be horribly abused to the point of admin costs and efforts delay work and cost effectiveness.
That's why I like to throw this out there- interested in others thoughts. I'm still on the fence but tipping to the existing Area/Iteration model.