To me, a project is defined as a set of iterations that make up a given release for a specified product.
It seems to me that the current definition in the way XPWeb is defined is that a project equates to a product.
The reason I say this is that for planning purposes, we generally enter a large number of user stories. These are not attached to an iteration at first. The engineering team then attach a weight and risk to the user stories. After that, the product manager will assign a priority to the user stories. This would all be done in the pre-planning phase.
Once that is done, we then create our iterations assigning user stories to them. However, it may happen that some user stories do not make it into any iterations for a given project(release). We would then need to move the user story to a different project in order to be included later. However, there is currently no facility in XPWeb to move user stories between projects.
So, we have named the project the name of the product, and have included the release name in the iteration name. For example, 'Columbia - Iteration One'.
However, over time each project is going to keep getting more and more iterations and the performance is going to suffer.
It would be very nice to be able to move user stories between projects. Then, I would be able to create one project per release rather than the way we currently do it.
If I tried to do it this way now, I would have to manually copy the user stories. This has a negative side effect that the user story number changes.
SouprMage
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tell me if I'm wrong, but having an set of iterations representing a release is in theory a good solution, isn't it?
Because for our next XPWeb release, I'm working on optimizing planning display. In particular, the page weight won't increase in time: when you'll hide old iterations, they won't be loaded at all (thus the page's weight will be only based on current iteration).
Wasn't it the main pb that made you create a project per release?
Olivier
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that the 2.2 release will resolve some of the issues mentioned above. Being able to hide previous iterations will definitely enhance performence in general. However, I feel the performance is still a bit sluggish.
Also, being able to move stories and tasks between projects would still be nice. It would allow for two different models. The first being the way it is done now, where a project really means the same thing as a product and you add iterations as you go. The other allowing projects to represent releases of a given product. In order for this to be effective though, user stories and tasks that are not completed for a given release would need to be moved to a different project.
In my opinion, having the option of using two different models would make the tool more useful to more development teams.
SouprMage
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll look at the "move to project" function: that should be very easy so why not to do it?
Not soon unfortunately: I can't spend so much time on XPWeb anymore.
Any skills in PHP? ;-)
Olivier
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To me, a project is defined as a set of iterations that make up a given release for a specified product.
It seems to me that the current definition in the way XPWeb is defined is that a project equates to a product.
The reason I say this is that for planning purposes, we generally enter a large number of user stories. These are not attached to an iteration at first. The engineering team then attach a weight and risk to the user stories. After that, the product manager will assign a priority to the user stories. This would all be done in the pre-planning phase.
Once that is done, we then create our iterations assigning user stories to them. However, it may happen that some user stories do not make it into any iterations for a given project(release). We would then need to move the user story to a different project in order to be included later. However, there is currently no facility in XPWeb to move user stories between projects.
So, we have named the project the name of the product, and have included the release name in the iteration name. For example, 'Columbia - Iteration One'.
However, over time each project is going to keep getting more and more iterations and the performance is going to suffer.
It would be very nice to be able to move user stories between projects. Then, I would be able to create one project per release rather than the way we currently do it.
If I tried to do it this way now, I would have to manually copy the user stories. This has a negative side effect that the user story number changes.
SouprMage
Tell me if I'm wrong, but having an set of iterations representing a release is in theory a good solution, isn't it?
Because for our next XPWeb release, I'm working on optimizing planning display. In particular, the page weight won't increase in time: when you'll hide old iterations, they won't be loaded at all (thus the page's weight will be only based on current iteration).
Wasn't it the main pb that made you create a project per release?
Olivier
Sorry for the late response.
I think that the 2.2 release will resolve some of the issues mentioned above. Being able to hide previous iterations will definitely enhance performence in general. However, I feel the performance is still a bit sluggish.
Also, being able to move stories and tasks between projects would still be nice. It would allow for two different models. The first being the way it is done now, where a project really means the same thing as a product and you add iterations as you go. The other allowing projects to represent releases of a given product. In order for this to be effective though, user stories and tasks that are not completed for a given release would need to be moved to a different project.
In my opinion, having the option of using two different models would make the tool more useful to more development teams.
SouprMage
Late response from me too...
I'll look at the "move to project" function: that should be very easy so why not to do it?
Not soon unfortunately: I can't spend so much time on XPWeb anymore.
Any skills in PHP? ;-)
Olivier