In planning a release or iteration the subset of user stories that are going to be developed during that release or iteration are identified. This subset needs to be depicted in StarTeam somehow
Continued from Agile requirements...
In planning a release or iteration the subset of user stories that are going to be developed during that release or iteration are identified. This subset needs to be depicted in StarTeam somehow so that it is easy to work with the user stories in a particular release or a particular iteration.
In traditional release management, labels are applied to the artifacts that comprise the release. However, release and iteration planning is a slightly different situation. We are not identifying a snapshot in time of a set of finished items; we are identifying a starting point, the contents of which may change. Therefore, the use of labels is not necessarily the right approach.
StarTeam has a number of grouping constructs:
Filters on specific values of custom fields
Revision labels
View labels
Promotion states
Folders
One way to represent the release and iteration a user story is in, is to create custom fields that can be set to the name of the release and iteration. Filters can then be created that display only the user stories in a particular release or iteration.
While this seems like an intuitive solution, there are a few problems with it:
To move a group of user stories or tasks into a release or
iteration, a user needs to open each one individually and set the
appropriate field. This is tedious.
It is hard to store other information about a release or iteration such as start date, end date, team capacity, etc. The only way is to encode this information into the value of the fields.
What type of field to use?
Using a numeric field means everyone needs to remember what number iteration and release is being talked about and eliminates the possibility of saving any other information about the release or iteration by encoding it into the value.
Using a more descriptive string field requires everyone to type the name correctly when setting the field so that the filters work correctly.
Using a field whose values are picked out of a dropdown list requires those lists to be set up and modified if encoded information changes..
StarTeam provides the ability to easily create, attach, move and detach revision labels on individual items including tasks and the requirements that might be representing user stories.
Traditionally revision labels are used to identify all the items involved in a particular item of work such as the resolution to a particular defect or provision of a particular new feature. However, we could create a revision label for each release and iteration and attach them to the relevant user story (requirement) and task items.
Revision labels have description fields where extra information about a release or iteration can be stored and we can ask StarTeam to select the items with a particular revision label and create reports and exports based on that selection.
We can also attach the label to a selection of user stories or tasks in one user operation.
However, there is a critical problem. StarTeam does not allow filters to be based on labels. This makes it very hard for users to see lists of just the user stories for a particular release or iteration within the StarTeam user interface.
StarTeam organizes each of it’s projects into one or more views. Views are used for a number of purposes including :
partition a project so that different people see different subsets of the contents
branching to enable work on different editions of a product to be managed
viewing snapshots of the project contents made at project milestones
View labels are labels that are automatically applied to all the contents of a StarTeam view when the label is created. View labels are typically used to identify a release of completed artifacts in traditional release management. They are particularly good for identifying snapshots in time. Therefore, for example, a view label could be created that identified the versions of all the source code files, users stories (requirements), tasks, and other documents and artifacts for a particular release, end of iteration snapshot, or successful build in a continuous integration scheme.
However, view labels are not particularly suited to identifying a subset of items from an overall set. Therefore, they form a poor choice for representing the ‘work in progress’ releases and iterations needed to hold user stories and tasks in agile project management.
A promotion state is a state through which a product passes. For example, most software products go through a release or production cycle. That is, the product moves from developers to testers and back again, until it is ready to go to the marketplace. Promotion states in StarTeam provide a convenient mechanism for ensuring that the right files or other items are available to the right people at the right stage of this cycle. For example, if a software administrator creates Test and Release promotion states, files that are ready for testing can be assigned to the Test state and files that have been tested successfully can be assigned to the Release state.
Promotion states are based on view labels and therefore do not represent a good way of representing the ‘work in progress’ releases and iterations needed to hold user stories and tasks in agile project management.
Rather than tag the user stories with a label or with a custom field, another way to indicate that they belong to a release or iteration is to create a folder for the release or iteration and move the user story into that folder.
This has a number of advantages over the labelling and custom field approach.
The structure of the releases and iterations can be made explicit by nesting iteration folders inside release folders and release folders inside a root user story folder or ‘Product Backlog’ folder.
All new user stories can be initially added to the root user story folder and assignment to a release or iteration is a simple drag and drop operation.
StarTeam has an ‘All descendents’ feature that enables users to list all the contents in a particular folder and its subfolders. Combining the use of this with nested folders representing releases and iterations, users can easily list all the user stories or all the tasks in a project, or release even if the user stories are actually in iteration sub-folders.
User stories can be moved in and out of releases and iterations as desired. Views and view labels can be used to create snapshots of the state of affairs whenever desired, for example, at the start and end of iteration or release so that the difference in user stories contained can be compared.
Like labels, folders have a description field where extra information about a release or iteration can be recorded.
Given the above using folders to organize user stories and tasks into releases and iterations provides a number of advantages over the use of custom fields, revision labels, view labels, and promotion states.
Strictly speaking a Scrum project does not use User Stories. Scrum use two different backlogs of items, the product backlog and sprint backlogs.
A Product backlog contains items for all the functional requirements for the project, additional technical work, defects, enhancements, etc known at the time.
Items are moved from the product backlog to a sprint backlog representing the set of items committed to be delivered in that sprint (iteration).
During a sprint, team members also keep the sprint backlog up to date by adding any new tasks and entering the estimated number of hours required left to complete an item.
All the same arguments listed for and against the different ways of storing user stories in StarTeam apply equally to organising requirements and tasks into Product and Sprint backlogs.
Therefore, StarTeam folders are the best way to organise requirements and tasks into different levels of backlog in exactly the same way they do for user stories.
In practice, many Scrum teams have adopted the use of user stories from eXtreme Programming and restrict their Product Backlog to containing only these. Many Scrum teams also split their project into releases and then into sprints (iterations).
Continue to Burn down charts...