Portfolio metrics provide direction

Agile portfolio metrics are integral to prioritization and validating the flow of work. The term portfolio has many uses in a software development organizations, ranging from product portfolios to application portfolios.  I have even seen scenarios where organizations put all their development, enhancement and maintenance efforts into a single bucket for prioritization and queuing until there was the capacity to work on them.  We will use an inclusive definition of the portfolio to include, at a high level, all the software development and enhancement work in an organization. Products, lines or business, and even applications are often used to define portfolios.  I break Agile portfolio metrics into five high-level categories. (more…)

Portfolio Estimation?  A life coach might help!

Portfolio Estimation? A life coach might help!

I recently asked a group of people the question “What are the two largest issues in project estimation?”   The group were all involved in delivering value to clients either as developers, testers, methodologists and consultants.  The respondents experience ran the gamut from Scrum and eXtreme through Scaled Agile Framework (SAFe) and Disciplined Agile Development (DaD) to waterfall.  While not a scientific survey, the responses were illuminating.  While I am still in process of compiling the results and extracting themes, I thought I would share one of the first responses: all resources are not created equal.  The respondent made the point that most estimating exercises, which begin at the portfolio level, don’t take into account the nuances of individual experience and capacity when projects are “plucked” from a prioritized portfolio to begin work.  This problem, at the portfolio level, is based on two issues.  The first is making assumptions are based on assumptions and the second is making decisions based on averages.  At the portfolio level both are very hard to avoid.

Nearly all organizations practice some form of portfolio management.  Portfolio management techniques can be range from naïve (e.g. the squeaky wheel method) to sophisticated (e.g. portfolio-level Kanban).  In most cases the decision process as to when to release a piece of work from the portfolio requires making assumptions about the perceived project size and organizational capabilities required to deliver the project. In order to make the assumptions, a number of assumptions must be made (a bit of foreshadowing, assumptions made based on assumptions are a potential problem).  The most important set of assumptions that are made when a project is released is that the requirements and solution are known.  These assumptions will affect how large the project needs to be and the capabilities required to deliver the project. Many organizations go to great lengths to solve this problem.  Tactics used to address this issue include trying to gather and validate all of the requirements before starting any technical work (waterfall), running a small proof-of-concept project (prototypes) to generating rapid feedback (Agile). Other techniques that are used include creating repositories that link skills to people or teams.  And while these tools are useful for assembling teams in matrix organizations, these are rarely useful at the portfolio level because they are not forecasting tools. In all cases, the path that provides the most benefit revolves around generating information as early as possible and then reacting to the information. 

The second major issue is that estimates and budgets divined at the portfolio level are a reflection of averages.  In many cases, organizations use analogies to generate estimates and initial budget numbers for portfolio-level initiatives.  When using analogies an estimator (or group) will compare the project he or she is trying to estimate to completed projects to determine how alike they are to another. For example, if a you think that a project is about 70% the size of a known project, simple arithmetic can be used to estimate the new project.  Other assumptions and perceptions would be used to temper the precision.  Real project performance will reflect on all of the nuances that the technology, solution and the individual capabilities generate.  These nuances will generate variances from the estimate.  As with the knowledge issue, organizations use many techniques to manage the impact of the variances that will occur.  Two popular methods used include contingencies in the work breakdown schedule (waterfall) and backlog re-planning (Agile). In all cases, the best outcomes are reflective of feedback based on performance of real teams delivering value. 

Estimates by definition are never right (hopefully close). Estimates (different than planning) are based on what the estimator knows very early in the process.  What really needs to be built becomes know later in the process after estimates and budgets are set at the portfolio levels.  Mature organizations recognize that as projects progress new information is gathered which should be quickly used to refine estimates and budgets. 


Climbing flight is a project, climbing them all is a program

Climbing flight is a project, climbing them all is a program.

Release planning generally focuses on the process needed to deliver functionality from projects. Projects are a central fixture of business, so it is easy to overlook program and portfolio release. Release planning for portfolios, programs and projects each has similarities and differences.

Project Level Release Plans: The project release plan describes what the team plans to deliver and when they intend to deliver.  These are a reflection of the team’s capability (reflected in the team’s velocity) and the product owner’s prioritization and strategy. An individual project’s release plan is very focused on the team’s ecosystem and generally has more a tactical orientation.  Project release plans are typically very granular, showing individual stories.

Program-Level Release Plans: Program release plans have to reflect a significantly larger number of moving parts than an individual project. The Project Management Institute (PMI) defines a program as a group of related projects, subprojects and program activities. Programs, because of their breadth, have more dependencies between projects and subprojects and will require more coordination, which impact both technical and business components. For example, earlier in my career I participated in a number of bank merger projects. Those projects were classic programs that included account conversions, application changes, signage/branding changes and business process changes. A change in the plan for one component could potentially cause a change in all of the rest of them. Also after a point the cutover date was nearly impossible to change. Developing a program release plan reflecting the needs and worries of a wide range of product owners is more than just assembling a view of all of the project release plans. Typically program-level release plans are less granular than project release plans showing the delivery of features and epics (collections of stories).

Portfolio-Level Release Plans: Portfolio management exists to help organizations maximize the impact of IT or project budget. In a perfect world, the portfolio of IT projects would be driven by the organization’s strategy and anticipated business value. Projects that are critical to business strategy and deliver the highest value would be prioritized, and then magically there would be capacity within the organization to tackle the project/program in the prioritized order. That magic is reflected in portfolio release plan. Portfolio release plans use inputs that include the organization’s strategy, estimates of business value and budgetary cost, the projected capacity AND technical capabilities to generate a plan that forecasts the evolution of the overall organization. A typical portfolio release plan will be at a high level showing product, programs and projects.

All three release plans are related. Project release plans influence program release plans and program release plans influence portfolio release plans. However, each release plan is not simply an aggregation from one level to the next. Project-level release plans are the most granular and are generally a reflection of the product owner’s needs and team performance.  Program-level release plans require negotiating the needs of multiple product owners, recognition of potential dependencies and reflect the performance of multiple teams. Portfolio release plans must integrate and balance organization level needs, capacities, capabilities and even politics. All three are important and having one does not lead linearly to the next.