Portfolio Planning for Agile Enterprises

Rally Software | 2014

Web app

high fidelity Rally Portfolio planner screenshot


Rally’s Portfolio Scenario Planning tool (code-named ORCA) was an R&D project that attempted to address a core problem area in Agile enterprises.

One of the biggest challenges of running agile in an enterprise-sized company is reconciling the need for projections and an annual portfolio with the workforce-focused process of Agile. Agile begs for flexibility in its path while annual planning asks for a visible map. Both are needed to run a true-agile enterprise.

Built with a small, fast, and lean team in the satellite office in Seattle (<20 employees in total at its peak, with only 1 designer an 1 intern designer in the end), Rally spent less than 1 year building out an MVP before launching.

In 2015, Rally launched its limited beta version to a standing-room audience at Rally Con 2015, where we signed up 10 beta clients and had to file an overflow waitlist.

About Rally Software

Rally Software is a project management application built to run agile processes at the enterprise level. Similar to Jira, Rally’s core product is an agile project management system (sprints, tickets, Kanban boards, etc).

Rally was acquired by CA Technologies in 2015, which was later acquired by Broadcom in 2018.

About Rally Portfolio Scenario Planner

Codenamed ORCA Rally's Portfolio Scenario Planning tool allowed portfolio managers (or other senior strategists) to play with “what-if” scenarios by comparing resource organization & expertise with the company's objectives & future work. It allowed the user to draw out possible options and outcomes, tentatively commit to one, and forward along the plan to product teams and departments be consumed by the next level of management.

Similar to a Gantt chart, ORCA was meant to allow a portfolio manager to plot and track actual progress over time. However unlike a Gantt chart, ORCA was also meant to be functional with only vague ideas of timelines and project sizes (as is the case with true Agile).

Key Highlights

  • UI separates global data from scenario workspace while making clear the workspace is a safe environment to play with data
  • User flow provides a suggested linear path to complete a scenario. This path can be done out of order, but is ideally completed one step at a time
  • UI clearly separates the definitions of supply and demand when looking at objectives, expertise, and resource allocation
  • Lean UX methodologies were used and adapted to a highly agile and collaborative development team


As a young new-to-Rally designer, a lot of the processes and rules of agile-enterprise management were new to me, so I was reliant on client feedback and sales relationships to do my work.

The ORCA project team worked in a truly lean agile process, pair programming and cycling tickets ever 1-2 weeks. To match the pace, low fidelity mockups were used for the majority of the app’s development.

Balsamiq sketches, whiteboard drawings, and sometimes independently-created prototypes were often used with both the team and the user testers/clients for feedback.

paper sketch of work planning

Paper sketch of the demand prioritization screen

whiteboard sketch of work allocation

Whiteboard sketch of supply/demand allocations

The 1st step to creating an effective portfolio management tool was to understand the overall user flow and create a higher vision of the user experience within our product. Interviews were conducted with selected clients and I gathered valuable insights from key sales representatives within the team.

From their insights, we understood that in order for portfolio management to work within the Rally ecosystem, the user needed a space to play with company data safely. There needed to be a separation between data that is global and data that is within a scenario playspace. To address this, our designs started with a "drawer" concept, where a drawer is used to represent the global data and the whitespace outside of it as the "scenario". Data is then brought in to the scenario’s workspace by the user and manipulated there. Anything within the scenario stays in the scenario until the user completes the planning process and chooses to take the plan out of the scenario.

balsamiq sketch of adding demand to a scenario

One of the images from the submitted set low-fidelity mockups depicting the expected user interaction in a series of storyboards

high fidelity mock of demand screen with drawer open

The Preliminary Scoping (or "demand") screens were later done in high fidelity for a testing prototype.

high fidelity mock of demand screen with expertise shown and drawer open

Many clients needed to portfolio plan with specific resource expertise limitations, so we included mocks with this type of toggle

high fidelity mock of demand screen with expertise shown and drawer open

With the drawer closed, the user could ignore often-giant backlog of features and focus on the scenario.

high fidelity mock of demand screen with expertise shown and drawer open

Closing the drawer also made analyzing expertise capacities easier with the valuable screen width

Interviewing different clients made clear that everyone had a different process for portfolio creation that was not easy and not consistent. However, a desire for guidance in this was expressed universally. We built a linear process that simplified the thought process behind portfolio planning, but did not restrict the user down its narrow path. This helped provide guidance while not being overly prescriptive.

balsamiq sketch of defining resources for a scenario

In the ideal flow, a portfolio manager would first define the limitations of their scenario's resources, defined as "teams" or "delivery groups"

balsamiq sketch defining demand in a scenario

Once resource capacities were defined, the portfolio manager would then look to identify the desired goals of the scenario, defined as "initiatives" and "marketable features"

balsamiq sketch of splitting demand in a scenario

Whole initiatives could be dragged into a scenario, but if the user only wanted to consider part of it, pieces could be returned to the "drawer".

high fidelity mock of scoping demand

Once initiatives and features were added to the scenario's list and stack ranked, the user could do a "preliminary scoping pass", using the cut-off line to define the portion of the list that makes it to the next step. This went through several high-fidelity iterations to make sure the UI was intuitive to the users.

balsamiq sketch of resource allocation`

This is where the "supply" and "demand" met. The portfolio manager could allocate resources to initiatives/features and vice versa. If anything was over-capacity, they'd get a warning but wouldn't be stopped from experimenting.

sequencing the work into time

Sequencing was the next step that brought time into the equation. Based on pre-defined timeblocks, the portfolio manager could then allocate work & teams over the year before generating a summary.

The user could input data and play with the tool at whichever step desired, but there was an ideal process:

  1. First, determine your capacity limits by defining what supply you can bring in to your scenario.
  2. Next, determine the objectives and features you want to get done and scope them.
  3. Next, bring the supply and demand together.
  4. Then allocate the "projects" to timeblocks within the defines scenario timeline
  5. Finally, generate a summary and risk report to be used for further discussion during annual planning meetings.

Each step of the way checks the ones before and details the plan a little more. At the end, a summary informs you of your completion status, how your resources are being spent and what the future timeframe has in store for your teams and objectives.

Rally planned to launch the 1st closed beta at their 2015 Rally Con, so we were working with a deadline. In order to meet MVP and make it for the grand launch, we had to descope the sequencing feature and risk assessment with plans to implement it after announce.

Likewise, further plans with ORCA included completely itegrating it into the Rally ecosystem by having scenarios able to be committed and trickled down through the project management tools. At its initial launch, ORCA provided a summary that could be communicated to the project managers and viewable in a widget.

Project ORCA was emblematic of lean UX process and lean agile development within an enterprise in and of itself. We focused on the business objectives and delivered on schedule with minimal overtime and burn within the team.