OTB tasks workflow

OTB use JIRA to monitor the task workflow and deal with new features and improvement. All member of the OTB community can post a new issue (New Feature, Improvement, Bug). The OTB team will answer to this task and deal with them if necessary. This task workflow is based on agile method principle and the GreenHopper plugin of JIRA.

The principal steps of this workflow are:

• An user or a developer create an issue on JIRA:
  • with a short but informative title
  • with a detailed description of the issue
  • with the following types: New Feature, Improvement and Bug (currently related to a MANTIS issue)
• These issues provide to the OTB-Team a general backlog in which we can find some interesting new issues for OTB. We can also consult periodically these issues to
  • close them if there are not relevant,
  • merge them into existing one,
  • discuss about them.
• During the first meeting after a release, the OTB-Team establish the Release Plan which list all the new features, improvements or closed bugs needed to release a new OTB version.
• After this meeting, no new features can be added to this new release plan but small improvements and bugs can be added into this plan during sprint meetings.
• Practically, these issues are marked with the corresponding Fix Version and for the New Feature issue they are transformed into Epics. The Improvement task are transformed into one Story or into a Epics which regroup different Stories. The description of each issue integrated into this release plan is enhanced to provide the current status, the goal and a short proposal about how to do that.
• This release plan given to the OTB-Team a version backlog in which we can take tasks for the next sprint.
• During the first sprint meeting, OTB-Team:
  • decide which issue of this version backlog which will done during the sprint.
  • discuss about this issue to give more informations to the developers team about the technical solution or constraints.
• During one sprint, developers can add technical sub task into the stories and should add comments about the progression.
• During the second sprint meeting, OTB-Team:
  • review and comment the issues of the previous sprint
  • decide which bug reported by users into the general backlog during the sprint should be added to the following sprint.
  • decide if some technical tasks should be closed as Won't fixed and postponed as future Improvement (and go to the backlog).
• and over and over until the release meeting which:
  • review the remaining tasks and decide if they should be closed as Won't fixed and postponed as future Improvement (and go to the backlog).
  • decide the release of the new version

The following scheme try to resume the OTB Workflow:

OTB task workflow