- 1 User Stories
- 1.1 User Story Workflow
- 1.2 Sub-Pages for Active 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
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.
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.