This is a TFS-specific question. If this is inappropriate for this site, let me know where I can ask it. I initially posted it on StackOverflow, but didn't get much of a response.
We have recently transitioned from Gemini to TFS for application change control. There is one aspect of TFS I can't get my head around - the lack of a built-in concept of the application version that each work item will be addressed in.
In Gemini every feature request, enhancement, bug etc can be tagged with a version number. If the field was left blank, the item was "unscheduled", i.e. on the backlog. Each version could be flagged as either released or not. Reports could be then created listing the issues addressed in each released version, i.e. release notes, and the issues to be addressed in future versions, i.e. a roadmap. I was completely happy with this!
Now in TFS I can't find any built-in concept of version. It seems like there are 2 ways to represent version:
As a parent item in the iteration tree, e.g.
- Sprint 1
- Sprint 2
- Sprint 3
- Sprint 4
As a parent item in the work items tree, e.g.
- Requirement 1
- Requirement 2
- Requirement 3
- Bug 4
The latter approach looks better because it allows versions to be worked on simultaneously (e.g. a major release will be worked on at the same time as bug-fix release).
So what is the recommended approach to managing work by version?