Agile Planning

What is Agile Planning?

From a bird's eye perspective, planning is the activity that aligns the teams to the common project goal. It translates business objectives to features and user stories that the team needs to solve to reach the project goal.

During planning the team defines the series of releases, possibly with their release dates and goals. Releases are then broken into multiple sprints, each with a prioritized list of work items. Work items are elaborated to the necessary level, without big upfront design work.

What is the Planner?

Planner is the primary interface in CodeBeamer to support all aspects of planning:

• Defining releases
• Breaking releases into sprints (or subreleases)
• Defining the work to do
  • Creating new work items (user stories, tasks, tests, etc.) or updating existing ones
  • Moving work items from backlogs to concrete releases or sprints and vice versa
  • Prioritizing work (defining the order in which the work items should be done)
  • Assigning work to team members (defining who is responsible for which work item)
  • Estimating work using Story Points

It is important to note that Planner can be successfully used, not only with agile, but also with other methodologies. More traditional methodologies like Waterfall or V-model can leverage the quick interactions in Planner, to define the release schedule, defining and assigning work, and so on.

Definitions: Release, Sprint, Backlog

The way CodeBeamer is modelling the important concepts of the Agile Release Train In is explained below. All these definitions are kept simple for easier understanding.

Release is any top-level item in a Release type tracker. There is one such tracker created in each project by default, but you can add any number of them later. A release may or may not have children.

Sprint (or subversion) is any non-top-level item in a Release type tracker. In simplest case, you only use two levels: topmost for tracking releases, and their children to track sprints. You can nest sprints in arbitrary depth if two levels are not supporting your processes correctly.
We also use the term subversion interchangeably for these items. There is no real difference between the two. In this aspects, the agile world breaks a release into sprints, while other methods break them into subreleases.

Backlog is the ordered list of open work items that need to be done at some point. There are multiple types of backlogs, see the next definitions.

Project Backlog is composed of the open work items that are not scheduled to any release or sprint. In other words, their Target field is left blank. The items are existing, but it is not defined when to address them.

Release Backlog is composed of the open work items that are scheduled to a release, not to a sprint. These should be addressed in that release, but it is not defined in which sprint.

Sprint Backlog is composed of the open work items that are scheduled to a sprint, but have not been done yet.

Planner Scopes

Planner can be used in multiple scopes, from top to bottom:

1. Project scope: in this scope, you work with all releases and sprints defined in the Release tracker. This is the biggest scope, which may be useful when re-organizing the release hierarchy, or when moving work from the project backlog to release and sprints.
   You can open this scope by clicking the Plan Releases link in the right panel of the release list.
2. Release scope: in this scope, you plan a single release together with its sprints. Sprints (or subreleases) can be nested in arbitrary depth, enabling you to set up a highly granular release hierarchy and cadence.
3. Sprint (subrelease) scope: in this scope, you plan a single sprint or subrelease. This is technically pretty much the same as the previous one, but we are separating it from a conceptual point of view.

Navigating between Planner, Cardboard and Release (or Sprint) Statistics

Planner does not add any additional information to your existing configuration and work items, but provides a way to browse and manipulate them in a view that is highly optimized for planning work and balancing load on your team members. Other views like Cardboard and Release (or Sprint) Statistics come helpful in other situations:

What are these perspectives primarily designed for?

1. Planner: to create and manipulate your release hierarchy, create and organize new work items with a quick and simple feedback on team commitment
2. Cardboard: to give a graphical visualization of your work items' status and give a way to intuitively change their statuses back and forth in the tracker's workflow
3. Release (or Sprint) Dashboard: to provide a detailed statistical overview of your (sub)releases and information on overall progress of development

For convenience, CodeBeamer lets you quickly switch between these contexts without losing focus. There are multiple ways to switch from Planner:

1. In the top right part of the Planner screen, using the large view switcher icons:
   
   
   
   (Please note that not all of these items might be available, depending on your scope.)
2. In the top right corner of every release and sprint listed in the center part of the Planner screen, you can find an icon to quickly switch to that specific release's (or sprint's) Cardboard.

Anatomy of Planner

Planner screen can be broken down into three big regions:

1. Left pane: contains three collapsable sections:
   1. A release hierarchy called Sprints, with lower level subreleases having a bigger indentation to visually indicate their place in the release tree. Only the release/sprint of the current scope and its children plus the backlogs (if applicable) are visible here.
   2. Listing of teams, which are participating in the release or its sprints.
   3. Listing of project members, who are assignee of at least one work item in the release or its sprints.
   4. Relations can be used to optionally categorize work items by requirements and/or user stories and use custom colors to make them visually easier to distinguish on the interface.
2. Center pane: contains a filtered, orderable list of work items with their most important properties displayed: priority, key, type, summary, Story Points (if enabled), assignees, teams and release targets.
3. Right pane: a quick view feature to see more details about a selected item without fully opening it. This information is broken into four sections, all of which are collapsable for convenience:
   1. Details
   2. Description
   3. Relations
   4. Comments

In the top part, above these panes, you may find the action bar that is useful if you want to toggle the left or right panes or if you want to quickly create a new item or a new (sub)release. The quick icons above both the left and the right pane are useful if you want to quickly toggle their corresponding sections.

Filter Widget

From codeBeamer 9.1 it is available to use the Filter Widget to filter the items. See more about the Filter Widget here.

In Planner you can filter by projects / trackers using the Project and Tracker selectors, these lists contains the project and trackers which are related to the current release. Furthermore you can filter by any default, reference and custom fields, and some other options just like in Reports page and on the Filter Widget.

Please note that Group by is available in Planner from codeBeamer 9.2. If you select Order by, ordering by drag&drop is not possible.

You can add more fields into the layout using the Add field option of the context menus of the header.

You can reorder the layout using the options of the context menu (Move left/right) or using drag&drop. If you do not need a column, you can remove it (except the Summary field).

It is able to drag&drop a field from the header to the Filter or Order by area, just like on the tracker's Table View.

Views can be stored also in Planner using the View Menu button, similar as in Table View. The saved views will be stored for the Release tracker and can be used in Planner and Cardboard pages of any releases/sprints or in tracker context.

Story Plan / Grouping Work Items

From codeBeamer 9.2 you are able to group the work items up to two levels. Use the Group by icon of the Filter Widget and select from the field list - default fields, common reference fields, or custom fields (they are structured by projects and trackers).

Grouping by reference field

If you select a reference field as Group by (Team, Upstream reference or any reference custom fields), you can rank the groups using drag&drop handle of the group header. You can use the group ranking in Release / Sprint scope and within the Product Backlog also.

If you group by reference field, the Relations tab of the left pane will represent the same structure as you see in the center pane - but without the items. You can reorder the groups in this section also using drag&drop.

You can also directly create new References through the context menu.

You are able to manage the groups also, using the drag&drop functionality - if you drag a group, you can move the items within the group in one operation to an other Release/Sprint, or assign to a Team or Member or set another Relation. So, all of the drag&drop operations are allowed for the groups which are allowed for a single item.

When items are grouped based on a reference field, the user has the option to mass expand or collapse groups of items in the planner area. To expand or collapse all groups in the planner area, use the Expand all or Collapse all options in the top right-hand side corner of the codeBeamer window:

It is also possible to expand or collapse one group only in the planner area. To do this, use the and buttons for the group that you want to expand or collapse:

Note: if you expand or collapse items for one specific group in one sprint in the planner area, the same group will be expanded or collapsed in all other sprints at the same time. For example, if you collapse the group of items assigned to Development team 3 in the QA sprint (see screen-shot above), all the groups of items assigned to Development team 3 will be collapsed in all the other sprints at the same time.

When a group is collapsed, all the items (for example, tasks, bugs, and so on) included in the collapsed group will still be visible on the right-hand side panel under the section References:

The right-hand side panel always contains the details related to the group that was last collapsed.

You can always use the drag and drop function to move items from one group to another, even if the target group is collapsed. However, if the target group is collapsed, you will not be able to move the transferred item to a specific position within the new group. In this case, you need to move the item to the target group first, then expand the target group, and then move the new item to the required position within the target group.

Assign items to groups

If you group by a reference field, and you move an item from a group into an other group, the item will be automatically assigned to the group where you drop the item. It means, the reference field what you used for Group by, will be updated for the moved item.

Additionally, you are able to create new Group Item, using the + New Group Item button next to the table headers. After you click the button, you will see an overlay in which you have to select, in which tracker you would like to create the new item. The project and tracker list depend on the field itself what you used for grouping and the field configurations of the affected trackers. For example, if you have Task items in the Release Planner and you use the Upstream Reference field for grouping, you will able to create a new User Story Item.

Clicking on the Next button, the new item overlay will appear. After setting the proper data and saving the new item, it will appear on the top of the table, and you can start drag&drop item(s) below the new item and the item(s) will automatically assigned to the new item via its proper field. Please note that if you not assign any item to the new group item immeditately after you created it, it will disappear after the next operation (e.g. you use other filters an click on GO button).

Please note, that if you have items in the Release Planner from multiple trackers, assignement cannot be done in any cases due to the filed configuration of the item - field can be missing for the item or the field could not accept the type of the group item. In that cases, you will see error overlay messages about the unsuccessfully operation.

The Product Backlog

In every Planner scope, you may find a Product Backlog tab in the bottom of the left pane.

This is a special tab and works a bit differently than the other release/sprint tabs in a way that is split into two sections, only one of which is visible at a time:

1. Product Backlog: this is basically a list of all work items that has no target (sub)release(s) set.
2. History: contains the work item history for the user currently logged in.

Note: The Product Backlog is also available directly from the Release Dashboard view:

Ordering Product Backlog

Product Backlog has two parts: an ordered and unordered part. The ordered part of the Product Backlog is empty by default.The difference between the two parts of the backlog is that ordering the Work Items is only supported within the ordered part of the Product Backlog. Use the Work Item context menu to add it to the ordered Product Backlog or use the + button to add to the bottom of the ordered Product Backlog.

This Product Backlog shows both parts:

All actions on Work Items in the Product Backlog require sufficient permissions. The application uses permissions of the default Release Tracker (if there are multiple Requirements Trackers, then the oldest one) for such actions. User must have Issue - Edit Any permission to execute actions in the Product Backlog:

Managing Releases in Planner

Watch a video on the release planner here.

Releases and sprints are the timeboxed iterations to represent the schedule according to which development work is accomplished, and which results are delivered. Planner makes it possible to configure this schedule conveniently and efficiently.

Creating and Deleting Releases

You can create a new (sub)release by clicking the Create Release or Create Sprint link (depending on your current scope):

It depends on your scope where the new (sub)release will be inserted:

• If you are in Project Scope, a new release will be created with no parent.
• If you are in Release Scope, a new sprint will be created as a child of the current release displayed in Planner.
• If you are in Sprint Scope, a new sprint will be created as a child of the current sprint displayed in Planner.

You can delete an existing (sub)release by using the context menus in the left pane. Please be aware that if you delete a (sub)release, all of its direct and indirect children will also be deleted.

Moving Releases

If you created a release or sprint in the wrong place or your release plan just changes over time, you can rearrange your hierarchy any time with a convenient D&D interaction. For most (sub)releases in the left pane, you will find a little draggable knob on their left that you can grab and drop that item into another one. That makes the dropped release (and all its child tree hierarchy) a children of the release or sprint you have dropped it into.

You can move a release to a sprint, a release to a release, a sprint to release or a sprint to a sprint, they will be converted automatically. However, there are some basic restrictions:

• You can not drop a (sub)release to itself.
• You can not drop any sprint to its direct parent release or sprint.
• You can not drop a (sub)release to any of its direct or indirect children (that would make a circular reference in the release hierarchy).

Freely sorting releases and sprints are not allowed by this D&D interaction, because the order is defined by their release dates (on the same level). If dates are not set or equal, ordering is by name.

Converting Releases to Sprints and Vice Versa

As mentioned in the previous section, conversion is done automatically, one way to do that is using D&D. There is also another way that is especially useful if you want to move a release or sprint out of its scope (i.e. to a higher level invisible in the current scope).

If you open a (sub)release's context menu, you will find a Move up item that will move that item one level up in the hierarchy. Basically it has the same effect as moving a sprint into its grandparent via D&D.

Of course, this menu item is only available for sprints because releases do not have any higher level to push them up into.

Managing Work Items in Planner

After you built the backbone of your Agile Release Train by setting up the release schedule, you should select what work to do in what iteration.

Filtering Work Items

In larger projects, you may find yourself trying to find existing work items between backlogs of thousands of items. Planner enables you to easily and efficiently filter through the items in the center panel, to find the needle(s) in the haystack.

You can filter work items against:

• Their current release, sprint or backlog: click a tab in the left panel.
• Their current assignee: click a row in the Members table on the left.
• Their current team: click a row in the Teams table on the left.
• Their referenced requirement and/or user story: click a row in the Relations table on the left.
• Free text matching: enter some search terms in the filter box in the top. The items that do not contain the entered term will be hidden from your view.
• Work Item Type: dropdown in the action bar.

Clickable filters can be removed by clicking again on the same UI element.

From codeBeamer 9.1 you can user the Filter Widget also.

Moving Work Items from Product Backlog to a Sprint or Release

You can use in Product Backlog all the features available in other pages (D&D, in-place editing, reassigning, filtering).

To assign work items to a specific release or sprint, just drag and drop them to that (sub)release on the left, possible drop targets will be highlighted.

Another alternative is the work item context menu:

Here you will get some hints where to move the item, or even send it back to the release or project backlog if it is possible.

Moving an individual Work Item to a different Release

It is possible to move individual items to:

• Other Sprints within the same Release
• Other Release Backlog (ordered / unordered parts)

These options can be accessed through the Work Item's context menu:

Moving all Work Items to a different Release

If you need to move all Work Items form a Sprint or Release to a different one, then it is better to use the specialized functions accessible from the following context menus:

or

Please keep in mind that only open Work Items (not resolved or closed) will be moved to the target Sprint or Release. These context menus contain menu option for all Sprints from the same Release, and the first 10 Releases.

The same functionality also exists on the Kanban Board:

and on the Release Dashboard:

Creating New Work Items

You can create a new work item by clicking the New Item link.

First, a project and tracker selection popup window will appear where you can set where to create the new item. On first open, the currently browsed release tracker's project will be set by default. If you will be creating more than one work item this way, you may find useful that this window will remember your selections on next launch. In the Tracker dropdown, you can only select work item trackers, so configuration items cannot be created here in Planner.

After proceeding, you will get the usual tracker-specific form where you can fill in the new data. After saving, Planner will refresh itself and select the newly created item automatically.

From codeBeamer 9.3.0, you can also add a new item to a specific group of items directly. When items are grouped by a choice field (for example, Priority or Severity) or a reference field, you can create a new item in the release/sprint by clicking the icon next to the group name. For example:

When the create window opens for the new item, the reference field by which the items were grouped (in this example, the Assigned to field) will be automatically filled in by the selected value (in this example, Product Manager).

Editing Work Items in Planner

In Planner, you can choose from two options to edit a work item:

1. Overlay editor: the "traditional" way. You can fire up the familiar item editor form in a popup overlay window.
2. In-place editor: provides a way to quickly edit some basic fields in the center pane without opening any complex dialogs.

It is important to note that both ways performs the necessary security checks, so you will only be able to see or edit the fields which you have enough permissions for. To open the overlay editor, you can click on any work item key in the center pane. If you do not have enough permissions to edit the item, a simple read-only listing of the fields will appear.

To make use of the in-place editor, watch for the grey outline on mouse hover around the fields in the center pane:

For these outlined fields, you can initiate in-place editing by double clicking them, which will immediately bring up their corresponding input field right inside the item listing. From there, you can use keyboard shortcuts to speed up your work:

• Esc will discard all the changes you made and exit in-place mode
• Enter will save your changes and also exit in-place mode

From codeBeamer 9.1 in-place editing is working for almost all of the fields (table fields are not supported) - of course if you have permission to edit the field. Built-in read-only fields are not editable (Assigned at, Submitted at, Submitted by, etc.)

From codeBeamer 9.3.0, in-place editing is also supported on the Preview panel of a work item (on the right-hand side area of the Planner).

Create New Downstream Reference

From codeBeamer 9.4.0, you can create new Downstream References for items by using the context menu next to the Summary field, and selecting a tracker under the Create Downstream Reference menu option.

Rating and comments

To add a comment to an issue on planner just select the item and after the properties were loaded to the right panel click on the Comments section. Here you can add new comments and read the comments from other users:

The rating feature is also available on planner. Behind the name of the issues there's an icon of stars. Loking at these icons you can easily see the average rating of the issues. To rate an issue click on this icon.

Prioritizing Work Items

By default, for a specific release or sprint, center pane will list work items sorted by priority, in descending order so higher priorities will come first.

Similar to the Release/Sprint Statistics screen, you can manually change this default ordering and rearrange work items by DD in Planner (if you have the proper access rights, of course). However, it is important to note that if you alter the ordering this way, the new manual item order will be attached to the containing release and you cannot get back to the automatic priority-based method again.

If you have too many items displayed on the screen, D&D might get a bit slow or unconvenient to be done. That is when the work item context menus come handy:

With Send to top and Send to bottom, you are not changing the target (sub)release but move the work item to the beginning or to the end of its list, respectively. There are a few similar options, which offer different amount of movement in these directions.

An interesting situation takes place if you have a filtered set of work items listed and you try to reorder them. This is a perfectly valid situation, but you should be aware that each item will remember the item you drop it after. A simple example will clarify that use case. Assume that you have an unfiltered list of items A, B, C, D. Now if you some way filter them down to A, B, D, then drop D after A, then drop it back after B, you will get the illusion that you maintained the original order. That is not true, if you remove the filtering to see all the items, the new order will be A, B, D, C.

Estimating Work Items

Agile encourages estimating complexity of work items expressed in so-called story points. This is a virtual unit, deliberately detached from real-world units like manhours or dollars.

CodeBeamer allows entering any type of numeric value as story point, although most teams prefer choosing values from the Fibonacci series (1, 2, 3, 5, 8, ...) or an exponential series (1, 2, 4, 8, 16, ...).

You can enter the Story Points value for a work item while editing that in-place in the center panel, or editing that in the overlay. Story Point values are automatically aggregated by user in the right, and by release and sprint in the left.

Assigning Work Items to Team Members

Planner is helpful in balancing workload on your team, especially if you use an agile development methodolgy with the concept of Story Points.

There are two possible ways to set a work item's assignee:

1. Overlay editing: see the Editing Work Items in Planner section
2. In-place editing: see the Editing Work Items in Planner section

You can of course set more than one assignee for a specific item, as usual.

Coloring items

If you set up a field with Color type for a tracker, you can specify a custom color for any tracker items individually (see Administratior's Guide for tracker configuration). This color should aid you in visually distinguishing items when you have plenty of them - the items' handles will reflect your setting.

If you use the Relations feature, a special rule apply for color resolution: if item has no color set, then it's "parent" user story color will override this empty value. If it's still empty, but the item has a "parent" requirement, that color will be inherited.

Using Relations to categorize items

Relations feature lets you categorize items based on their relationships with higher abstraction level items that they are logically related to. Practically that means you can group them by the requirements and/or user stories. This grouping is detected automatically via the fields of the work item's tracker (see Administratior's Guide for tracker configuration). To leverage this feature, you should:

• Set up a field from your tracker referring to user stories with any label
• Set up a field from your tracker referring to requirements with any label
• Set up a field from the User Stories tracker to a Requirements tracker

This will end up in a Relations hierarchy:

• Requirement 1
  • User Story 1
    • Work Item 1
    • Work Item 2
    • ...
  • User Story 2
  • ...
• ...
• Requirement 2
• User stories (without requirements)
  • User Story 1
  • User Story 2
  • ...

In action, only the first two levels are displayed, namely the requirement and the user story levels. You can then filter work items in the center pane by selecting one of the Relation items.

Item colors are also shown here, see previous section for information on how to assign color to any tracker item and how they get resolved in the hierarchy.

Note : only the first reference field is picked up for each examined tracker. If more than one is configured, any of them might be chosen by the system arbitrarily to detect relations.

From codeBeamer 9.2 if you use a reference field in the Group by section of the Filter Widget, the Relation section will reflect the result. It means, you will see the group headers in this section.

Show parent items

In codeBeamer 9.1 you can display the parent items of each items displaying in Planner. Check Show Parent Items checkbox on the left pane header, and you will see the parents of the items recursively. Each parents will get a label and indicator which have unique color, so if you have items with the same parents sequentally, these will be displayed as a group.

Parents can be displayed not only for Releases/Sprints, but for Product Backlog also.

Multiple selection

From codeBeamer 9.2 it is possible to select more items at once and manage the selected items in one operation. After you click on the Multiple selection section in the left pane header, there will be a checkbox for every item. You can select the items one-by-one, and use drag&drop operations for all of the selected items. You can assign items to other Release/Sprint, assign to teams/members/relations.

Click on the Multiple selection checkbox again to exit this mode and the checkboxes will disappear.

From codeBeamer 9.3.0, it is also possible to select all items in a sprint or release at the same time. To select all items in a sprint, click the Multiple Selection checkbox in the top menu and tick the selection checkbox in the header of the Planner area:

Generating Sprint/Release History

From codeBeamer 9.3.0, it is possible to display the history of work items within a sprint or release. To generate the sprint or release history of work items, click the icon next to the Release field under a sprint or release in the Planner area, and select the Show Sprint History menu item:

The sprint/release history of the items will now be displayed on the Planner area:

In this example, some of the work items have been transferred from "Design and implementation sprint 1" to "Design and implementation sprint 2".

Generating sprint schedule and next sprint

There is an easy way in codeBeamer to generate the whole release schedule or the next sprint for a release. Generating the sprint schedule means that you generate all the sprints that fit in a release saving a reasonable amount of time. To be able to generate sprints codeBeamer needs to know three things:

• the start date of the release
• the end date of the release
• the length of the sprints

Each release tracker has the necessary fields to set these things: Planned Start Date, Actual Release Date and Sprint Length. If the Sprint Length field is missing from your tracker a project administrator can create it with this configuration:

Once you have a release with these three fields set to new menu items are available in the release context menu:

These menu items do similar things:

• Create Sprint Schedule: based on your field settings it computes how many sprints fit in the release and generates them. Their name is inherited from the release name. If your release is called 5.0 then the first generated release will be named 5.0.1, the second 5.0.2 etc.
• Generate Next Sprint: if you already have some sprints in your release this item will generate a new sprint starting when the current last one ends. The length of the generated sprint comes from the Sprint Length field of the release. If the release is still empty this item will generate the first sprint.