Content
 BigPicture

About BigPicture

BigPicture installation

Quick start with BigPicture

BigPicture Export

Tutorials and tips

Integrations

 BigPicture release notes

BigPicture Cloud Backlog

Shortcuts
 Release notes
 BigPicture
 Jira Cloud

 Jira Server

 Trello

 BigGantt
 Jira Cloud

 Jira Server

 BigTemplate
 Jira Cloud

 Jira Server

 BigPicture Enterprise
 Jira Cloud

 Jira Server

Knowledge Base

Tutorials and tips

Search

This section applies to BigPicture version 7 and later.

About Roadmap

Our SAFe® based Roadmap module is a quite simple yet unspeakably effective tool which allows you to manage objectives of Program Increments and their iterations as well. Compared to Board module, it primarily concentrates on high-level planning including forecasts and commitments rather than particular tasks. This article focuses on basic concepts of "Scheduling with Roadmap". 

Agile schedule

Before the first use, you need to set out Agile schedule in your Program which is a set of Program Increments consisting of iterations. 

You can either create an Agile schedule using Generate schedule wizard located in Program configuration...

...or simply add new Program Increments providing all data manually. 


Automatic configuration of schedule can also be performed during Program creation process. (step 5.1. Agile schedule)

Iteration's/ Program Increment's lifecycle

There are three statuses for every iteration/ Program Increment:

  1. FORECAST - it will be executed in the future so it is still under planning
  2. IN PROGRESS - it is now during execution
  3. CLOSED - it has already finished.

All the following transitions between statuses are allowed. (Edit mode needs to be enabled first) 

FORECAST → IN PROGRESS and vice versa


IN PROGRESS/FORECAST → CLOSED and vice versa

When closing a Program Increment, a user is prompted to decide what to do with open objectives afterwards. 

All objectives previously marked as "Failed" will remain in a given status after reopening a Program Increment. These objectives will also be automatically cloned (these are later called instances) and added to the next iteration/Program Increment with status Open

Roadmap's timeline

A timeline gives you the ability to have an high-level overview showing key deadlines since the start of the first Program Increment till the end of the last Program Increment.

The undeniable advantage of Roadmap's timeline are markers that can be created all over its length. Markers are specific points along a development timeline (basically, they are key deadlines you need to keep in your mind). They can serve as reference points for anybody involved in the project or Agile Release Train (in case your company is SAFe® oriented). A sample marker can be an important event, a product demo or a day of internal review. 

Objectives

An objective is a high-level analogy to work that needs to be done in a given time period. They are a short summary that highlights what needs to be achieved, but do not determine the way it should be done. Such an approach provides more flexibility and team empowerment and allows you to focus on transparent specific objectives at the same time.  

To learn more about the nature and the goal of defining objectives click here

Objective's lifecycle

There are four statuses for an objective: 

  1. Open

  2. Completed - marked as green checkmark

  3. Failed - marked as red cross ((info)setting an objective as "failed" always clones it and adds to the next Time-box)

  4. Abandoned - marked with strikethrough.


Objective Types

We can distinguish some types of an objectives based on different criteria: 

  1. Time-box level

    • Iteration Objectives (which are basically Sprint goals)

    • Program Increment Objectives 

  2. Responsibility

    • Main Objective - they are used to eg. sum up Program Increment objectives of your ART at the end of PI planning

    • Team Objective - they are used to eg. determine team commitment during particular Program Increment

  3. Origin

    • Artificial Objective

    • Task Based Objective

Objective origin and responsibility are crucial information for planning and composing/decomposing objectives. 

Moving objectives

Objective can appear on multiple positions. It can also be given a different status for every single position. The main purpose of such a functionality is to keep track of objectives that there were not achieved. But it can be utilized in many different scenarios.

In general a single objective in a single position is defined as an objective's instance. User is allowed to create multiple instances of a particular objective in a Roadmap module (e.g. to set a shared PI objective for two team).

Creating new instances of the objective is simple and can be done either by:

  • selecting Continue... option or 
  • using drag and drop holding left Alt key.



Statuses of a given objective's instances can be managed from Details modal window. 

Objective can also be simply moved from position X to position Y using drag and drop (without holding any key) - aim to a white plus sign in a green circle and then drop the objective's instance. 

It actually means that an instance of the objective in position X is deleted and another one is added to position Y. 

Attaching objectives

It is common case that one objectives are consequence of other objectives etc. User is able to attach such an objective to create parent -> children relationship. There are multiple scenarios when such an attachment is needed. Achieving program increment objective like "release new version of the software" can be dependent on achieving other team objectives related to new functionalities. From the other side some Iteration Main objective (an objective of a whole Agile Release Train) can be result of multiple Team objectives that need to be achieved in prior to this Main Objective. To cover all scenarios and avoid illogical attachments following restrictions are defined:

  • Single objective can be attached only to one objective (multi partnership is not possible). 
  • Main objective A can be attached as child of other main objective B only if B objective's Time-box (e.g. PI) is parent of sibling of parent of A objective's Time-box 
  • Team objective C can be attached as child of main objective D only if:
    • D objective's Time-box is sibling of C objective's Time-box 
    • D objective's Time-box is parent of sibling of parent of C objective's Time-box

Please note that a status of an attached objective is always inherited from only the last position(s) of a base objective (in the all teams) and it cannot be overwritten by a user.

An app sets it automatically based on the following rules:

  • if at least one position is set as "failed" → set an attached objective as failed
  • if at least one position is set as "open" and any position is set as "failed" → set an attached objective as open
  • if at least one position is set as "completed" and any position is set as "failed" or "open" → set an attached objective as completed
  • if all positions are set as abandoned → set an attached objective as abandoned

Planned or Actual Business Value

Depending on the moment of the PI or iteration (planning or closing time) it is possible to define Planned Business Value (PBV) or Actual Business Value (ABV). 

Configure the visibility of Business Value fields on the Roadmap module in Program Configuration

Use a scale from 1 (lowest) to 10 (highest to assign a proper value to objective. Business value should not be confused with any other measures, such as the associated effort or total story points associated with an objective.

Keep in mind that the status of the Time-box determines the possibility to define or modify Business Value. The dependencies looks as follow:

Time-box statusActual BVPlanned BV
forecasteditable

not editable

in progresseditableeditable
closednot editablenot editable

Keep in mind, that attached objectives do not present its Actual or Planned Business Value (even if it exists), as attachment serves only for showing some dependencies between objectives.

In order to provide you with more flexibility, there is no dependency between objective status and its Business Values. It means that setting objectives as 'failed' does not calculate e.g. ABV - you are allowed to assign its value manually to a particular objective.

Sorting objectives

In case your Roadmap is configured to display Business Values for your objectives, you are allowed to sort objectives by its Planned or Actual Business Value.

Go to menu "View" and choose the way you want to sort objectives. It is possible to sort objectives alphabetically, by PBV or by ABV (every option available in ascending or descending order).


Keep in mind that once you perform sorting action, you always sort only the objectives that are currently visible in your Roadmap view.

Such a behaviour is deliberate in order to avoid unintentionally sorting some past or future objectives.


Achievement type

Roadmap module provides you with a measure to determine e.g. program predictability. By both main or team objectives you can see achievement indicator that is based on statuses or Business Value assigned to objectives.

Achievement is just a percentage of achieved objectives in a particular position. Go to menu 'View" and pick between 2 types of achievement:

  • based on statuses
  • based on Planned and Actual Business Value. 


The formula of the achievement indicator is simple: all successful objectives/ regular objectives * 100%.

In order to be in line with SAFe®, stretched objectives are treated as optional, they are always ignored in the denominator of the formula. Although, in case a stretched objective was marked as successful, it would be included in a numerator of the formula.


Please note, that you can switch off the visibility of team or ART achievement in Roadmap by selecting "None" option.

HIGHLIGHTS

  • No labels