Work Items
Work Item Description
When performing customization, you may work on a wide range of elements. You must group this changes into a unit of work called a Work Item (short name: WI).
A Work Item represents a set of changes. The nature of the grouping is up to you and can include a mix of:
• similar functional scope
• similar technical scope
• similar delivery constraint: project or timeline
Work Item states
A Work Item follows a linear life cycle:
• New
Default state at Work Item creation.
• Active/Working
As long as the Work Item is not defined as complete any user can use it to add customizations.
There is not duration limit.• Completed
The Work Item is closed and ready for extraction. Customizations can no longer be added.
• Extracted
The completed Work Item has been extracted to an *.mgr or *.xmg file. It is ready for the Build and Install Custom Package.
Naming convention
You should give an explicit name to your Work Item, for example a name regarding:
• a functional scope
E.g.: “Metamodel customization”, “Diagram customization”.
• a planned delivery version/time
E.g.: “Project Customization for V2”, “Next release sprint July”.
• a functional domain or project name
E.g.: “ITPM customization”, “Project A customization”.
You should avoid naming a Work Item with:
• a random name.
E.g.: “Work Item 1”, “Work Item 2”, “WI A”, “WI B”.
• a non-explicit name.
E.g.: “Oliver WI”, “Today Work Item”.
Recommendation
It might be useful to limit the number of Active Work Items to avoid confusion regarding their content and grouping.
In case you extracted completed Work Items that you do not want to add to the Custom Package yet, you can revert the entire last update, see Reverting the Last System and Data Update.