User Stories
The basic unit of work for the team is user story. The team's objective is to define, build, and test some number of user stories in the scope of an iteration and thereby achieve some even larger value pile in the course of a release. Each story has a short, incredibly intense development life cycle, ideally followed by long term residence in a software baseline that delivers user value for years to come.
Learn more about user stories in Wikipedia
Managing user stories
User stories are represented by issues in User Story type trackers in Codebeamer. There is one tracker of this type created in each new project, called intuitively User Stories. You manage user stories the same way like any other type of issues, but we go into details in the next sections.
Creating user stories
You can create a new User Story as any other type of issue. You can either add it on the tracker page or on the tracker list using the context menu.
A User Story is just a regular tracker item with one special field story points. Story point is a relative measure of the complexity of a User Story. You can specify one or more baseline user stories (preferably with different complexity), define their story points value and then use these to estimate the complexity of other stories in story points.
In Codebeamer the Story points field accepts any integer without restrictions.
Breaking user stories into actionable tasks
Often times, a user story is too large to be implemented as a single unit of work, and should be broken into multiple actionable tasks. For example, to implement a new report type, you need to:
1. Add new indexes to the DB scheme.
2. Extend the data access code with a new query.
3. Implement the web view to display the report results.
The default User Stories tracker is kept on the bare minimum, thus expressing this relation is not available out of the box. Nevertheless, you have multiple option to express implemented by between user stories and tasks, change request, bugs, and other types of issues:
1. Easy: Associate the user story with each additional issue it is implemented by.
2. Better: Customize the User Story tracker. Add a new multi value reference type field Implemented by. In this case, the relation is stored at the user story end.
3. Best: Customize each of the trackers that potentially can contain actionable tasks for user stories. Add a new reference type field Implements and make it required. In this case, the relation is stored at the task end.
Was this helpful?