Stupid Question about "Plan Items"
10 answers
Hi Aaron, here's what we say about Plan Items in the Team Concert 1.0 / platform 0.6 plan (https://jazz.net/development/DevelopmentItem.jsp?href=content/project/plans/jazz-plan-0.6.html):
"The bulk of the plan consists of plan items describing work to be performed on the Jazz Platform or a product configuration. Each plan item covers a new feature or API that is needed, or some aspect that should be improved. Each plan item has its own work item in the Jazz Project repository, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail. Requirements, proposals, progress reports, and ongoing discussion of a plan item are hosted at its work item."
"Not all plan items represent the same amount of work; some may be quite large, others, quite small. Some plan items may involve work that is localized to a single component; others may involve coordinated changes to several components; other may pervade the entire Platform. Although some plan items are for work that is more pressing than others, the plan items appear in no particular order."
From an implementation point of view, a Plan Item is just a custom work item type, which we've defined using Jazz's Process and Work Items technology. Plan Items also have a custom workflow which is different than more 'traditional' work items like "Enhancements" and "Tasks".
I couldn't say "Plan Items are like requirements" with a straight face, for the following reason:
- 'Requirement' is one of those terms that has many different meanings depending on the context of its use (i.e. on a federal project 'requirement' means one thing while on a web 2.0 project it might have a different meaning).
- The term Plan Item has a very specific meaning to the Jazz Team (see above) and we don't tend to use the word "Requirements" in our day to day vocabulary. That's not to say requirements aren't important, it's just we use different terminology that works for us. In the past we also had a concept of "RFS" (Ready for Shipping) work items which were basically the set of features without which we wouldn't declare Team Concert Beta 1 (June 2007) ready to ship to users and extenders. I haven't seen that term recently so I think "Plan Items" might have rendered RFS unnecessary (I'll ask Erich Gamma or Jim des Rivieres to correct me if I'm wrong).
Well there's a long answer to a short question :-)
"The bulk of the plan consists of plan items describing work to be performed on the Jazz Platform or a product configuration. Each plan item covers a new feature or API that is needed, or some aspect that should be improved. Each plan item has its own work item in the Jazz Project repository, with a title and a concise summary (usually a single paragraph) that explains the work item at a suitably high enough level so that everyone can readily understand what the work item is without having to understand the nitty-gritty detail. Requirements, proposals, progress reports, and ongoing discussion of a plan item are hosted at its work item."
"Not all plan items represent the same amount of work; some may be quite large, others, quite small. Some plan items may involve work that is localized to a single component; others may involve coordinated changes to several components; other may pervade the entire Platform. Although some plan items are for work that is more pressing than others, the plan items appear in no particular order."
From an implementation point of view, a Plan Item is just a custom work item type, which we've defined using Jazz's Process and Work Items technology. Plan Items also have a custom workflow which is different than more 'traditional' work items like "Enhancements" and "Tasks".
I couldn't say "Plan Items are like requirements" with a straight face, for the following reason:
- 'Requirement' is one of those terms that has many different meanings depending on the context of its use (i.e. on a federal project 'requirement' means one thing while on a web 2.0 project it might have a different meaning).
- The term Plan Item has a very specific meaning to the Jazz Team (see above) and we don't tend to use the word "Requirements" in our day to day vocabulary. That's not to say requirements aren't important, it's just we use different terminology that works for us. In the past we also had a concept of "RFS" (Ready for Shipping) work items which were basically the set of features without which we wouldn't declare Team Concert Beta 1 (June 2007) ready to ship to users and extenders. I haven't seen that term recently so I think "Plan Items" might have rendered RFS unnecessary (I'll ask Erich Gamma or Jim des Rivieres to correct me if I'm wrong).
Well there's a long answer to a short question :-)
I would add that we use "Plan Items" for our high-level project planning, and this work item type is particularly tuned to the Proposed/Committed/Deferred aspect of the Eclipse process.
That said, I have no problem saying that our Plan Items are like requirements :-)
We tend to use RFS items to track specific scenarios that need to be supported in the release, or other details.
That said, I have no problem saying that our Plan Items are like requirements :-)
We tend to use RFS items to track specific scenarios that need to be supported in the release, or other details.
I would add that we use "Plan Items" for our high-level project planning, and this work item type is particularly tuned to the Proposed/Committed/Deferred aspect of the Eclipse process.
That said, I have no problem saying that our Plan Items are like requirements :-)
We tend to use RFS items to track specific scenarios that need to be supported in the release, or other details.
Another question on this "Plan Items" work item type. I'm being draw in to a 'project' that wants to make my division's development more like jazz.net, but the plan is to gather data from "Plan Items". Near as I can figure this work item type is internal to the projects on jazz.net based on this post and the fact that no project I've ever setup has this work item type?
True or False ?
I would add that we use "Plan Items" for our high-level project planning, and this work item type is particularly tuned to the Proposed/Committed/Deferred aspect of the Eclipse process.
That said, I have no problem saying that our Plan Items are like requirements :-)
We tend to use RFS items to track specific scenarios that need to be supported in the release, or other details.
Another question on this "Plan Items" work item type. I'm being draw in to a 'project' that wants to make my division's development more like jazz.net, but the plan is to gather data from "Plan Items". Near as I can figure this work item type is internal to the projects on jazz.net based on this post and the fact that no project I've ever setup has this work item type?
True or False ?
False:
The out-of-the-box Eclipse Way process provides multiple predefined work item types, including the following:
* Defect: identifies a bug.
* Enhancement: describes a requested new feature.
* Plan Item: provides high-level description of work targeted for a specific iteration.
* Retrospective: records what went well and what did not go well in the recently completed iteration.
* Story: describes part of a use case.
* Task: describes a specific piece of work.
* Track Build Item: identifies the status of a build
False.
(:-)
A "plan item" is a category of work item types. You specify whether or
not a work item type is a plan item in your process configuration. In
particular, it is in the
Project_Configuration:Configuration_Data:Planning:Work_Item_Type_Categorization
section.
Every work item type that is not selected there as a plan item type is
an "execution item type".
This controls whether or not a work item type is displayed by default in
certain Plan Types (you can override by selecting the "show all work
items" box in the plan).
So you see plan items in every plan (including plans on jazz.net), but
you get to pick whether you also see execution items in certain plan types.
Cheers,
Geoff
On 9/12/2011 4:08 PM, yzwkzfn wrote:
(:-)
A "plan item" is a category of work item types. You specify whether or
not a work item type is a plan item in your process configuration. In
particular, it is in the
Project_Configuration:Configuration_Data:Planning:Work_Item_Type_Categorization
section.
Every work item type that is not selected there as a plan item type is
an "execution item type".
This controls whether or not a work item type is displayed by default in
certain Plan Types (you can override by selecting the "show all work
items" box in the plan).
So you see plan items in every plan (including plans on jazz.net), but
you get to pick whether you also see execution items in certain plan types.
Cheers,
Geoff
On 9/12/2011 4:08 PM, yzwkzfn wrote:
jeemwrote:
I would add that we use "Plan Items" for our high-level
project planning, and this work item type is particularly tuned to
the Proposed/Committed/Deferred aspect of the Eclipse process.
That said, I have no problem saying that our Plan Items are like
requirements :-)
We tend to use RFS items to track specific scenarios that need to be
supported in the release, or other details.
Another question on this "Plan Items" work item type. I'm
being draw in to a 'project' that wants to make my division's
development more like jazz.net, but the plan is to gather data from
"Plan Items". Near as I can figure this work item type is
internal to the projects on jazz.net based on this post and the fact
that no project I've ever setup has this work item type?
True or False ?
The fact that the Eclipse way has a work item type called "Plan Item" is
certainly a source for confusion (the newer process templates do not).
So the an Eclipse way Plan Item type is both a plan item (i.e. "not an
execution item") and a Plan Item (instance of the Eclipse Way Plan ITem
type).
Cheers,
Geoff
On 9/12/2011 5:53 PM, yzwkzfn wrote:
certainly a source for confusion (the newer process templates do not).
So the an Eclipse way Plan Item type is both a plan item (i.e. "not an
execution item") and a Plan Item (instance of the Eclipse Way Plan ITem
type).
Cheers,
Geoff
On 9/12/2011 5:53 PM, yzwkzfn wrote:
yzwkzfnwrote:I would add that we use "Plan
Items" for our high-level project planning, and this work item
type is particularly tuned to the Proposed/Committed/Deferred aspect
of the Eclipse process.
That said, I have no problem saying that our Plan Items are like
requirements :-)
We tend to use RFS items to track specific scenarios that need to be
supported in the release, or other details.
Another question on this "Plan Items" work item type. I'm
being draw in to a 'project' that wants to make my division's
development more like jazz.net, but the plan is to gather data from
"Plan Items". Near as I can figure this work item type is
internal to the projects on jazz.net based on this post and the fact
that no project I've ever setup has this work item type?
True or False ?
False:
The out-of-the-box Eclipse Way process provides multiple predefined
work item types, including the following:
* Defect: identifies a bug.
* Enhancement: describes a requested new feature.
* Plan Item: provides high-level description of work targeted for
a specific iteration.
* Retrospective: records what went well and what did not go well
in the recently completed iteration.
* Story: describes part of a use case.
* Task: describes a specific piece of work.
* Track Build Item: identifies the status of a build
An execution item is by definition, anything that isn't explicitly
specified to be a plan item (in your Process Configuration). So by
definition, every work item is either a plan item or an execution item.
Cheers,
Geoff
On 11/3/2011 9:38 AM, scottchapman wrote:
specified to be a plan item (in your Process Configuration). So by
definition, every work item is either a plan item or an execution item.
Cheers,
Geoff
On 11/3/2011 9:38 AM, scottchapman wrote:
It appears that Enhancements are not execution items nor plan items
(as far as I can tell).
I am unable to find Work_Item_Type_Categorization in my process
config
we are using the Scrum process config.