Create Your Portfolio in Rally.
Rally provides portfolio planning tools that help you plan your release,
determine if your teams have the capacity to execute on your plan,
and to collaborate throughout the portfolio process itself.
From the Portfolio menu, select the Portfolio Items page.
First, let’s choose the level or type of portfolio item we’re going to create.
Is it a larger initiative that will consist of multiple features?
Or is it the features themselves we’ll model?
Let’s start with the larger initiative of accepting a new form of payment
(in this case Gift Cards), for our online store.
Let’s use the Consumer Site project for this initiative, since it may be that
multiple teams in this project will be working on features for this initiative.
We’ll set the portfolio item type to Initiative.
Then we’ll select +Add New to add a new portfolio item at the initiative level.
Enter a name for the initiative and select the state that reflects where the initiative
is in our portfolio or program process for initiatives.
If we’ve had discussions about the level of effort needed for the initiative,
we can specify the preliminary estimate
(which is a very rough guess at the size of the work involved)
we can keep it unspecified if discussions around effort have not yet occurred.
Now let’s select Create with Details.
The Status options are relevant when the portfolio item has entered a point in the process
where it is being actively monitored or worked.
The Ready and Blocked statuses are helpful to indicate when a portfolio
item can progress on its journey across the Portfolio Kanban board,
or when it is stalled, and why.
In the Description area we’ll give details about the outcomes we want to achieve with this investment.
Perhaps we’ll mention timeframes, budgets, market influences, and other context for this initiative.
We can attach business plans and other supporting documents for this initiative.
In the Notes we can give some additional guiding information, or more detailed
information for planning and execution.
We’ll select a color that will help us track this initiative through the planning and execution process,
we’ll specify the owner or go-to-person for the initiative,
and continue to fill out the information that we haven’t already added.
Assigning tags helps with sorting, filtering, and reporting.
If we think we’ll address this initiative in the near future,
we might want to add a Planned Start or Planned End Date.
Providing both dates means that this initiative will show on the Portfolio Timeline page.
If we don’t know whether this initiative will be funded, or if we don’t know when
it will be planned, we can keep these dates blank.
Specify any milestones or market events that we want to associate with this initiative.
And if this initiative is part of a higher level theme
(which is another type of portfolio item), we can choose that theme here.
We can continue to specify more details about this initiative
such as whether it needs to be expedited, which investment category is paying for it,
and any prioritization scores that may apply.
As we get closer to the actual work on this initiative, we can give it
a refined estimate that hones in more accurately on the effort in story points
needed to deliver all the features in the initiative.
There are other values we can add that may be helpful in prioritizing this initiative’s work.
Now that we’ve got the basic information recorded, we can Create the initiative.
In our example, which shows the default portfolio hierarchy,
there are three types of portfolio items: Theme, Initiative,
and at the lowest level of the hierarchy, Feature.
Only the lowest level portfolio items have associated work for teams.
The features that support our Gift Card payment initiative are also known as the children
of the initiative - the next level of definition for each item of
customer value that helps deliver the entire initiative.
The easiest way to build out features for our initiative is to start with our initiative
and drill into details.
Select the ID of the initiative we just created.
From the initiative detail page, select the Children icon to view or add
features to the initiative.
We can select the team if we know which one will be the primary team to work on the feature,
or we can keep the same project as the initiative for now.
Multiple teams can work on a feature, but since we’re just getting
the initial information recorded now, we can leave the default,
or choose a team according to what we know at this point in time.
It’s a good practice to ensure that team members have at least view permission
for the project assigned to a feature and it’s initiative.
This allows team members to scope their views up and maintain context when working
on the stories associated with the feature.
Likewise, portfolio, product, and program managers
should also have at least view permissions for the teams that will be assigned user stories
associated with the refined feature.
This will enable them to scope down from the initiative or feature to understand the status of contributing work expressed in stories.
Let’s give our feature a name, an initial state -- and you can see that feature states
may be different from the initiative states -- and a preliminary estimate if we know it.
We probably don’t know it at this point.
Now let’s Create with Details.
We have the same options for status,
description,
attachments,
and notes as we did at the initiative level.
It’s a great practice to keep the color of the feature consistent with the color of its
parent initiative for easy scanning and association within other
contexts and pages in Rally.
Select an owner for the feature, and assign values if you know them
to the other remaining attributes.
We’ve already discussed the state and preliminary estimate attributes.
Like with most work items in Rally, we can assign one or more tags
to assist our searches, filters and analytics.
Since “Feature” is the lowest level of portfolio item we’ve defined for our organization,
it is most commonly scheduled into a mid-range planning timebox
—or release—when teams are ready to start on the work—or user stories—
that deliver the feature.
If we know the release we want to associate with this feature we can choose it now,
or leave it to be assigned later.
As with initiatives, we may specify further details
like planned start and end dates,
milestones, and other values to assist with prioritization.
As part of the planning process, product and engineering teams
will meet to discuss the details and delivery estimates for features,
breaking them down into child user stories that are further refined over time.
Portfolio items cannot have defects as children,
although defects may be associated with the user stories that are children of a feature.
Once work has begun, you can see the progress of a
portfolio item by using the Percent Done fields.
The value of the Percent Done by Story Plan Estimate field is
calculated by dividing the number of accepted story points by the total
number of story points associated with the Portfolio Item.
If your team plans and tracks using throughput measures,
consider the Percent Done by Story Count status which is derived from the number of stories
accepted divided by the number of stories associated with the portfolio item.
Hover over either of the Percent Done fields to see a summary of
progress from both perspectives, and to view any warnings that might affect the calculation.
As stories are accepted, or when stories are removed from a portfolio item,
the percent done values will recalculate.
At times there is a slight delay to display the new percent done values.
Hover over the information icon, or check the Last Rollup Date
to see when these values were last updated.
Other progress attributes include the Actual Start Date and Actual End Date for the portfolio item.
Actual End Date for the portfolio item.
The Actual Start Date is the earliest date an associated story is moved to an
In-Progress (or later) schedule state.
The Actual End Date is the latest date the final associated User Story
is moved to an accepted (or later) schedule state.
These progress indicators may be displayed on cards in a board view,
or in columns in a list view, by selecting Show Fields
and specifying the fields that interest you.
Select the Dependencies Icon to identify work that this feature depends on,
or to specify other features that rely on the completion of this one.
Identify predecessors by selecting the Predecessor tab,
and adding a new feature or linking an existing one
You’ll notice that you may only identify portfolio item dependencies
of the same type as the one you are editing.
You can view dependency relationships on board views,
list views, and on the Timeline Page.