Jump to: navigation, search

Difference between revisions of "ProductTeam/Development Proposals"

(User Story Workflow)
(Gap and Overlap Analysis)
Line 13: Line 13:
 
The team must conduct a technical gaps and overlaps analysis once a user story concept has been validated and any overlaps/conflicts with other proposed user stories have been remediated.  The user story owner and a technical SME will schedule a cross-project concept review meeting with the CPSL (cross project spec liaisons) from projects that would require blueprints/specs resulting from the user story.  This meeting will be used by the team to validate the approach/concept, determine whether any proposed user stories have to be deferred based on prior work inside the project(s), and the best way to proceed based on the outcome.   
 
The team must conduct a technical gaps and overlaps analysis once a user story concept has been validated and any overlaps/conflicts with other proposed user stories have been remediated.  The user story owner and a technical SME will schedule a cross-project concept review meeting with the CPSL (cross project spec liaisons) from projects that would require blueprints/specs resulting from the user story.  This meeting will be used by the team to validate the approach/concept, determine whether any proposed user stories have to be deferred based on prior work inside the project(s), and the best way to proceed based on the outcome.   
 
<br><br>
 
<br><br>
 +
 +
==== Implementation Plan ====
 +
The result from the gaps analysis meetings is an implementation plan.  The implementation plan is not a required artifact and can be conveyed verbally or captured in other artifacts (such as the user story priorities or user story tracker).    The goal of the implementation plan is to agree upon the next steps for a given user story whether that includes creating project level specs/blueprints, cross-project spec(s), or a new OpenStack project.  The implementation plan is to ensure that all parties agree upon the next steps (this includes the user story owner, user story technical SME(s), and cross-project spec liaisons for the relevant projects). 
 +
<br><br>
 +
 
==== Possible Statuses for User Stories====
 
==== Possible Statuses for User Stories====
 
<b>Proposed:</b> User stories are first submitted as a patch to this location in the repository.  In this phase, the user story will be validated against the template (e.g. all mandatory sections are filled out properly) and the concept will also be discussed using gerrit comments against the change.  The author/owner will should also submit new patch-sets to refine the user story based on the discussion.  The change will not be merged (e.g. visible on the [http://specs.openstack.org/openstack/openstack-user-stories/ specs page]) until the user story has reached a point where the concept is considered validated by the team.<br><br>
 
<b>Proposed:</b> User stories are first submitted as a patch to this location in the repository.  In this phase, the user story will be validated against the template (e.g. all mandatory sections are filled out properly) and the concept will also be discussed using gerrit comments against the change.  The author/owner will should also submit new patch-sets to refine the user story based on the discussion.  The change will not be merged (e.g. visible on the [http://specs.openstack.org/openstack/openstack-user-stories/ specs page]) until the user story has reached a point where the concept is considered validated by the team.<br><br>

Revision as of 21:35, 13 June 2016

User Stories

The Product Working Group discusses proposals, both, internally and externally using user stories. The user stories are created using a standard template which is located on the Product WG Repository. The process for proposing and, eventually, implementing user stories is depicted in figure 1.1. The primary source for information on Product WG user stories is our specs page, the user story sub-pages listed here are meant to provide additional information about the team that is working on the user story (members, meeting times, etc.) and supporting artifacts for the user story that do not fit the defined template.

This taxonomy shows more details on the mapping on product WG mapping to agile terminology.

User Story Workflow

User Story Workflow
figure 1.1

The workflow covers the proposal, refinement, acceptance, and implementation of the user story. Anyone is allowed to post a user story to the proposed folder in the repository.

Gap and Overlap Analysis

The team must conduct a technical gaps and overlaps analysis once a user story concept has been validated and any overlaps/conflicts with other proposed user stories have been remediated. The user story owner and a technical SME will schedule a cross-project concept review meeting with the CPSL (cross project spec liaisons) from projects that would require blueprints/specs resulting from the user story. This meeting will be used by the team to validate the approach/concept, determine whether any proposed user stories have to be deferred based on prior work inside the project(s), and the best way to proceed based on the outcome.

Implementation Plan

The result from the gaps analysis meetings is an implementation plan. The implementation plan is not a required artifact and can be conveyed verbally or captured in other artifacts (such as the user story priorities or user story tracker). The goal of the implementation plan is to agree upon the next steps for a given user story whether that includes creating project level specs/blueprints, cross-project spec(s), or a new OpenStack project. The implementation plan is to ensure that all parties agree upon the next steps (this includes the user story owner, user story technical SME(s), and cross-project spec liaisons for the relevant projects).

Possible Statuses for User Stories

Proposed: User stories are first submitted as a patch to this location in the repository. In this phase, the user story will be validated against the template (e.g. all mandatory sections are filled out properly) and the concept will also be discussed using gerrit comments against the change. The author/owner will should also submit new patch-sets to refine the user story based on the discussion. The change will not be merged (e.g. visible on the specs page) until the user story has reached a point where the concept is considered validated by the team.

Cross Project Spec Created: Once the user story is ready for community discussion, the user story owner will submit a change to the cross-project specs repository and update the user story in the "proposed" folder with a link to the cross-project spec review. The user story owner will also create an initial user story tracker using the user story tracker template with only the user story related fields completed.

Cross Project Spec Accepted: This is a user story that has now become an accepted (merged) cross-project spec and is ready for an implementation plan (which includes component level blueprints and socialization with project teams). The user story owner, at this phase, will update the user story in the "proposed" to include a link to the actual cross-project spec (replacing the "review" link that was entered in the previous phase). The user story tracker should also be updated to include the cross-project related fields and any project-level specs/blueprints information as it becomes available.

Conditions For Movement of User Story

User Story Idea -> Proposed Change/Patch: Anyone can submit a user story to this folder, this is the starting point for user stories

Review Proposed -> Merge Proposed: The user story must meet template standards (e.g. all mandatory sections completed) and the concept has been refined by the Product WG through the gerrit review process.

Merged Proposed -> Cross Project Spec Change/Patch: A user story owner must be identified at this point and they are responsible for creating the cross-project spec submission. The user story owner will also change the "cross project spec link:" to "ready to submit" in a single-line change to the proposed user story, this indicates to the Product WG that this user story is about to be submitted for review by the technical community/cross project team. An initial tracker for the user story must also be created by the user story owner so the OpenStack community can track the status of the user story moving forward.

Sub-Pages for Active User Stories

Quotas, Usage Plans, and Capacity Management

Lifecycle Management for VMs

Onboarding Legacy Apps into OpenStack

Rolling Upgrades

Highly Available VMs