Working in backlog views

Backlog views display all the requirements of a package and provide options for creating, refining, changing, and prioritizing new requirements. Requirements can also be grouped, sorted, or edited directly.

Information of a backlog view

In the upper area of a backlog view, you can read various information, such as the name of the package in which the requirements are, and so on, as well as the total effort involved in the requirements.

Domain backlog

Release backlog

The front number can be displayed in green or red. Green indicates that the effort of all requests is less than the planned effort of the activity. You can therefore drag additional requests to the activity. Red indicates that the activity is already overplanned. In this case, you should reschedule requests and drag them to another activity.

In the upper right area of the view, you will find various buttons that influence the display of the data:

Create new elements

You can fill the backlog by using the plus button to create new requirements or by dragging requirements from the product view into the domain backlog container.

If you drag requirements into a domain backlog, you can see in the upper part of the respective container how high the total effort of the requirements in the respective container is. If an activity has already been assigned to the domain backlog, you can see whether the activity is already overplanned or not.

Sorting

You can sort requirements (in alphabetical order, from the largest to the smallest value, and vice versa) and arrange them so you can find items faster. This is especially useful if the view contains many requirements, use cases, and so on. 

Sort requirements, use cases, etc. according to their properties by clicking in the respective column names.

Group

For a better overview, you can also group elements according to their columns. Drag the desired property (e.g. state) to the gray area above the column names. This groups the requirements according to states. This allows you to concentrate entirely on the group of features in the evaluated state.

The requirements are now grouped by their states and displayed in a list. Behind the states, you can see in parentheses how many requirements are in a particular state.

There are 47 requirements in the backlog requirements. One of them is scheduled, five are assessed, on is defined, and 40 have the state definition ongoing.

The grouping can be released by clicking on the x in the grouped column.

Creating relationships

You can drag requirements directly to another requirement, use case, and so on to create derivations, refinements, or dependencies.

The context menu of a requirement provides various commands:

You use Refine to create a new requirement that is automatically assigned to the selected requirement as a refinement. Use the subsequent dialog to select a target package. The refinement is then stored in this package.

You use Derivation to create a new requirement that is automatically assigned to the selected requirement as a derived requirement. Use the subsequent dialog to select a target package. The derivation is then stored in this package.

With Derive test case, you create a test case for the requirement. The test case can be seen in the processing dialog of the requirement on the Test Cases tab. Select a target package in the subsequent dialog. The test case is then stored in this package.

You use Create Dependency to create a new requirement that is automatically assigned to the selected requirement as a dependent requirement. Select a target package in the dialog box that appears. The dependent requirement is then created in this package.

You can use Schedule to assign the selected requirement directly to a release or even to a specific sprint. Select an activity in the follow-up dialog.

Show relationship

If you click on a requirement, you can recognize relationships to other requirements by the fact that different requirements are highlighted in color in the view. The requirements that are related to the selected requirement are also indicated by an icon that tells you what type of relationship they have to each other. This property of the view is useful, for example, if you want to define the ranking of epics that have arisen from a feature through refinement.

If there are relationships between the requirements, these are highlighted visually. On the left, the requirement Epic 2 is selected. You can see at a glance that the requirement Feature A and Feature M are related to Epic 2 and how the relationship is directed. The crosshair points to Feature M, indicating that it is the parent requirement. Accordingly, Feature A and Epic 2 are the refinements of Feature M.

Edit rank

Define a ranking (e.g. 1,2,3 or 10,20,30 or similar) to show which features, epics and user stories should be implemented first. Rank expresses how important it is to the stakeholder that the requirement is implemented. By default, a requirement etc. is ranked 50. You change the rank by clicking in the column and entering a new value. The item is then moved up or down in the list.

The rank can also be changed by clicking on the element and dragging it between two elements or onto an element while holding down the mouse button. The element then takes the rank of the element to which it was dragged.

The requirement Feature A has the rank 0. The requirement is dragged to the requirement Epic 2 using Drag & Drop. Since Epic 2 has a rank of 20, the requirement Feature A has rank 25 now.