Release Policy - Planning Cycle

Scope

• Feature Life Cycle Management includes features being subject to a Planning Cycle:
  • new features are planned and specified before being developed and included in future releases.
  • having passed the Planning Cycle new features are subjec to a Development Cycle.
• This article describes
  • the policy for feature planning
  • the mapping to the respective status in the Change Management System.
• Further resources for life cycle management
  • for the overall Product Life Cycle see Release Policy - Product Life Cycle Management
  • for information about release availability and maintenance see Release Policy - Platform availability and support

Life Cycle

Planned features will pass through the begin-of-life cylce with the following status before a decision is taken whether they will be developed or not:

OPEN

• A feature or bug has been added but might not yet be assigned to any developer or release.
• Open issues are assigned a release and are worked on in the course of this release.
• The next step will be to CLARIFY the feature, i.e. to collect requirements and to decide on future development.

CLARIFY

• The feature or bug has to be specified before any further status is assigned. This includes to check the validity of requirements and the feasibility.
• Issues for clarification are assigned a release and are worked on in the course of this release.
• Users are invited to vote for the feature and to comment by adding use cases and requirements that help to specify the feature.
• Subsequent to clarification the feature will then be ACCEPTED or DEFERRED for development, or it will be DISMISSED or classified as KNOWN ISSUE without further action.

KNOWN ISSUE

• The feature or bug is classified as a known issue, i.e. as an inconvenience with a valid workaround available, and will by purpose not be changed.
• Known issues are not assigned a release.
• Being a known issue is an end status for a feature, therefore no further action will be taken.
• The issue is assigned one of the resolutions
  • the feature works as designed (resolution: works as designed).
  • the issue not being fixed (resolution: won't fix).

DISMISSED

• The feature or bug is dismissed, e.g. due to architectural constraints or invalid requirements. The feature is not considered for future development.
• Dismissed Issues are assigned a release and are worked on in the course of this release.
• Being dismissed is an end status for a feature, therefore no further action will be taken.
• The issue is assigned one of the resolutions:
  • the feature works as designed (resolution: works as designed).
  • the issue is caused by misconfiguration or misapprehension of the underlying functionality (resolution: bogus).
  • the issue not being fixed (resolution: won't fix).
  • the issue duplicating an issue and being resolved with that issue (resolution: duplicate)
  • the feature requirements being incomplete (resolution: incomplete).
  • the bug cannot be reproduced (resolution: cannot reproduce). 

ACCEPTED

• The feature or bug includes valid requirements and is accepted for development with the assigned release.
• Subsequently the feature will proceed through the Development Cycle, see Release Policy - Development Cycle.

DEFERRED

• The feature will be considered for development in a future release.
• However, the feature is not assigned to a release. Instead, the feature is deferred for later consideration.
• The issue has no resolution assigned (resolution: Unresolved). Therefore the issue can be voted by the users in order for the company to prioritize these issues for future releases.