ALM: User Guide

User requirements are usually not done one by one, but in packages. This is because of a complex development process, less retesting waste, and because users are not interested in single requirements; they want a tangible result.

For this reason, unlike task managers, the finish date of several requirements is the end of an iteration or release, not a specific date for each requirement. When planning development, we set aside several iterations or releases, spread the requirements across them, and control the finish date of the whole iteration or release.

There are exceptions, and some requirements must be done by a specific date regardless of which release or iteration they are in. A primary requirement (issue or story) has a "Due dates" field where you can explicitly set the date by which the requirement must be done. Tasks also have "Start" and "Finish" fields, which let you control the start and finish dates of particular tasks precisely.

Due-date information for requirements and tasks is shown in these modules:

• My tasks - a list of tasks across all of the user's projects, with the date by which the tasks must be finished.
• Upcoming work - a list of tasks sorted by how urgent they are.
• Issue due-date control - a board of requirements where urgent or overdue requirements are shown at the top and future ones at the bottom. Requirements, in effect, float up to the top of the board.
• Plan - overdue releases or iterations are highlighted in red.

For convenience, every user receives a report of upcoming tasks in their projects by default. This notification can be turned off in the user profile.

The most urgent tasks are always shown at the top of the application, in the list of upcoming tasks.

Auxiliary attributes

Issues, requests, and enhancements have a separate "Finish estimate" attribute. The value matches the due date if a required finish date is set explicitly for this requirement. If the requirement is included in an iteration or release, their calculated finish date is used as the estimated finish date of the requirement. Otherwise the finish estimate is calculated from the team velocity and the effort estimate of this requirement.

Milestones are intermediate checkpoints on the project schedule that remind project participants of important dates. One or more requirements can be attached to a milestone. On the project plan, milestones are shown on a red background.

A sequential process (Kanban) aims to speed a requirement through the process chain from the start to the end. The main process metric in this case is your team's throughput. It can be measured as the average number of hours needed to implement a requirement. The smaller this value, the more effective your process is and the higher the team's productivity. This value is called average cycle time.

For a more detailed picture of how long a requirement (or task) spent at each stage of the process, use the "Lifecycle" tab on the task or issue view or edit form. The "Cycle time breakdown" report analyzes stage duration for a set of issues or user stories.

Use the "User Story Lead time distribution chart", which shows how the number of completed stories depends on their cycle time in days

When a "parallel process" is used, for example Scrum or Scrumban (for a new release), the main Agile metric is team velocity. It shows how much work the team can complete in one iteration (sprint). The amount of work is expressed as a number of requirements (if they are similar and small), or as complexity estimates, for example Story Points.

Team velocity can change from sprint to sprint. A steady rise in the average means the team is working more effectively. The "Development velocity" report tracks this indicator. It compares planned and actual velocity.

Sprint dates are controlled with a burndown chart:

The yellow line shows the planned amount of work. The red line is the required amount of unfinished work for each day of the sprint. The green line is the actual amount of unfinished work. The blue line is the forecast for completing the sprint. If the green line stays under the red line, you will finish the sprint on time.

An alternative view of the work plan is a roadmap, which shows when a given piece of functionality will be developed or will be ready.

Delivery chart shows the planned delivery dates of functionality. You can drill the chart down to features or specific issues, and show completed and future issues, using the filter settings.

Release planning (an operational plan, or grooming) shows future releases and iterations and their contents, and lets you distribute issues across releases or iterations.