DevelopmentProcess/Planning

Contents 1 Overview 2 Feature request collection 3 Feature request triage 3.1 Feature request validity 3.2 Feature request relevance 3.3 Feature request priority 3.4 Optional attributes 4 Feature request scheduling

Overview

The Planning phase of the development process consists in determining the feature candidates for a particular release.

The process is divided in three sub-phases:

1. Feature request collection
2. Feature request triage
3. Feature request scheduling

Feature request collection

Feature requests are collected on an on going basis using the Openbravo Issue Tracker.

For more details on this see the Feature Reporting Guidelines.

Large, relevant feature ideas are being made available for public voting. This is a primary source of planning input. So go there, have a look and vote for the ideas that matter most for you!

In this context, the public may also contribute additional proposals that are not yet logged in the issue tracker. These will then be logged there.

To suggest a feature for inclusion, go to the [voting page]. First have a look if what you are missing has already been proposed. If not, add it.

Feature request triage

Once logged, feature requests are in status New, which means that they have not been triaged yet.

The triage process occurs on a continuous basis as feature requests are reported. A new request should be triage within a week of its creation date

The goal of the triage process is to assess:

1. The validity of a feature request
2. Its relevance
3. Its priority

Feature request validity

Valid feature requests are set into status Acknowledged, which notifies the reporter that the request has been received and considered valid.

Invalid feature requests are rejected, which sets them in status Closed, with a resolution type that justifies the rejection. Feature requests could be rejected if they are a duplicate of an existing request, if the functionality is already present in the latest version of the product, or if they are not aligned with the high level product road map.

In case the feature request is not clear enough, it is set in status Feedback, which notifies the reporter that additional information is required.

Feature request relevance

In most cases, valid feature requests are significant functionality on their own. Examples of such requests would be: "Payroll application", "Intrastat report", or "Enhanced search flow".

In other cases, however, the feature request is very small in scope and it is best considered in the context of another larger request. For example: feature request 0000303: Terminology: Inconsistent use of Business Partner, Employee and Operator is too small to be worth a planning exercise by itself and it is best considered as part of the larger request 0000504: Label clean up.

To distinguish these two situations, the ReleaseCandidate tag is used.

In addition to be set in status Acknowledged, significant functionality is tagged with the label ReleaseCandidate.
Smaller features, instead, do not have this tag but are marked as child of a larger feature by establishing a "blocks / depends on" relationship with them. This means that only the larger feature request needs to be planned and that when it is executed all the smaller requests it depends on must be considered as well.

Using this mechanism, a list all the feature requests considered important enough to be planned independently can be obtained by querying the feature requests in status Acknowledged or Scheduled and that have a Release Candidate task. For example, you can view such list for Openbravo ERP.

Feature request priority

The priority of feature requests is being determined through public voting.

It is important to notice that this is only an initial assessment and it can be changed at any point in time depending on a number of factors, including changes in the market. The final priorities are set in the product backlogs used by the teams.

Optional attributes

During triage, other attributes of the request can be optionally assessed:

• Effort: a high level assessment of the effort required to implement the request.
• Owner: the person responsible for managing the request through resolution.
• Category: the product area mostly impacted by this request. This category will also identify which Scrum team will be handling the request.
• Additional tags: additional classification elements. The following tags are commonly used:
  • ReleaseCandidate: see Feature Request Relevance
  • ModuleCandidate: the request could be implemented as an independent module in addition to a core feature.
  • Localization: the request, although not related to any specific localization effort, enables localization capabilities. Example: 0004139: Unicode fonts in iReports is a change in the Openbravo ERP platform that enables usage of iReports in countries using extended character sets.
  • Usability: the request, although not strictly related to a feature of the Openbravo user interface framework, affects the product usability. Example 0003328: clear all permissions to a role is related to security (role management) and makes it more usable.

Feature request scheduling

The outcome of this process is a fully prioritized list of feature candidateswith the release-defining core features first, and then more features following in order of descending importance.

Within Openbravo, the items on this list are then assigned one by one to the responsible Scrum Product Owners:

• Features concerning the technical foundation: Platform 

• Features for accounting and localization: Localization

• All other features: Community Support

From this point on, the corresponding product owner is resonsible for the feature. He remains bound to the overall prioritization of the feature candidates.

The product owner then details the feature request initially by requesting input from Openbravo's User Experience, Documentation and QA specialists and merging their feedback with his thoughts into a list of functional requirements.

He then splits the functional requirements into small chunks of functionality that can be delivered gradually. Each of them is expressed as a user story and carries a set of acceptance criteria which are later used to judge completion.

The product owner then blends all these user stories with necessary other ongoing development, refactoring and bugfixing efforts. The result is a unified product backlog for his team(s).


When user stories are included into an upcoming development sprint, the corresponding feature requests are marked as Scheduled, meaning that the status of the request is set to the homonymous value and the target release is set to the upcoming release. At this point, this list will become available in the Road map page of the Issue Tracker.

Category: Openbravo Development