Jump to: navigation, search

StoryBoard/Story Types

User stories

  • Project drivers want to be able to distinguish between features that are "new features" and those that are "improvements", in order to prioritize review work
  • Release management needs to distinguish between bugs (which can be merged after feature freeze) and features/improvements (which can't)


Stories should have a type. Stories may change types as we realize their true nature.

Basic types are hardcoded in StoryBoard, since they may trigger specific workflows. Extended types are optional, defined for a given instance of Storyboard, and borrow their workflow to a basic type.

The following types are proposed:

Basic types (hardcoded in StoryBoard)

  • Bug (an issue that was detected in current code)
  • Feature (new functionality. Increases technical debt. Shows up separately from bugs in milestone reports)
  • Vulnerability (an issue with security consequences. New vulnerabilities are created private. Shows up separately from bugs/features in reports)

Extended types (would be defined in the OpenStack instance)

  • Improvement (feature that radically improve ways current things are done. Reduces technical debt. Borrows behavior from feature)
  • Regression (bug in an area that was working perfectly well in the last release. Borrows behavior from bug)
  • Other (catch-all for other types of stories. Borrows behavior from bug)


New table:

  • storytype: list of available story types. Contains a behavior column that points to a basic type

New fields:

  • stories should have one new column:
    • story_type referencing a row from story_types (defaults to bug)