StoryBoard/Story Types
< StoryBoard
Revision as of 10:13, 27 August 2014 by ThierryCarrez (talk | contribs) (Created page with "== 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 w...")
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)
Design
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)
Implementation
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)
