Kanban Board

Alternative name(s)

Programme management; portfolio management (Gardiner, 2005).


Multiple projects are managed in the traditional project approach as programmes or as portfolios.

A programme is a group of projects that together contribute to achieving an organisation's business strategy (Cadle & Yeates, 2004). In effect, it is one large project with sub-projects, carried out for a single client, and has a fixed pool of resources (e.g. people, equipment, finance).

A programme director or programme champion will be responsible for programme management‍‍‍.‍‍‍
Their responsibility is to:

  • Continually decide on the relative priority of the projects;
  • Manage and settle conflicts that arise through project leaders competing for scarce resources such for each of their projects;
  • Ensure an optimal usage of the pool of resources available, and thereby keep a control on the programmed costs.

Kerzner (2013) suggests using a prioritisation system to manage multiple projects efficiently. However, on the downside, inefficient prioritising of a project may lead to its failure. Managing scope change of multiple projects is difficult to achieve. ‍‍‍Kerzner (2013) advices managing scope changes in multiple projects as ‘performed through enhancement projects’.‍‍‍

‍Agile values‍

Individuals and interaction against processes and tools play an important role in managing multiple projects in agile. An Agile portfolio will include several projects whose requirements (User Stories) will make up the Product Backlog.
In the Scrum Release Planning meeting; attended by the Scrum Masters, Product Owners, and the Scrum team, user stories are typically combined into Themes (group of related User Stories). Release Planning then involves prioritising the themes.
The result of this face-to-face meeting is a release plan agreed and committed by all stakeholders.

Responding to change is more important than following a plan. This Agile value is also applied when managing multiple projects.
In an agile environment, projects are backlog of user stories (Product or Sprint Backlog). Development of a project may begin within a Sprint (Iteration). However after several Sprint Reviews, the Scrum team may decide to give the project a lower priority and returned it to the Product Backlog, or it may be stopped entirely if it is not meeting the expected business value of the customer.
Rapid feedback of the project's performance enables adaptive planning, and ensures that large investments are not made towards projects that are no longer capable of meeting business values.

Agile principles

For the understanding of common goals, better decision making and information sharing, communication is fundamental to managing multiple projects simultaneously in Agile. Poor communication between the Product Owner/s Scrum Master and the Project Teams can result in late iteration (Sprint) releases and a failure to provide the product correctly. Daily Meetings and monitoring the Sprint Backlog of multiple projects is key to multiple project success. (Zarnett, 2012).
In Agile, teams are empowered to work under their own control, allowing the teams to be creative and limiting them only by that creativity. Teams in control of their own destiny reassures the Scrum Master / Project Manager that the teams will deliver on their goals / sprint goals. (Zarnett, 2012).

Agile practices‍‍

A Product Backlog may contain User Stories relating to: 1) one project and one customer; 2) multiple projects and one customer; or 3) multiple projects and multiple customers. The Planning Game is therefore essential in prioritising the these User Stories during Release and Iteration Planning.

The Planning Game is an XP practice whereby User Stories are prioritised and chosen for the Release and Iteration phases. In the Release Planning, the Customer and Developers prioritising what product features or functionality (User Story) to include in the next Release. In Iteration Planning, the Developers prioritise what to include in the next Iteration. Prioritising is according to: 1) The business value it will bring; 2) cost of developing and supporting it; and 3) the amount of risk reduced for that project by developing the Theme.
‍Business value can be measured by estimating the financial value of implementing the product feature or functionality. Qualitative methods such as desirability; is the product's feature mandatory or optional can also be used. Techniques such as: 1) MoSCoW (Must, Should, Could, Won't); and 2) Kano's (et al., 1984) customer satisfaction model (desirability = must-haves; pleasant to have; and delighters). can also be implemented to measure the business value of a product feature qualitatively.

Estimation of a User Story into Story Points relative to other User Stories provides the means of estimating of the cost of developing that particular product feature.
In XP this is done in Planning Game, whilst in Scrum it is carried out in the Planning Poker.‍

Scrum of Scrums scaled up to multiple projects allows for inter-project team communication and incorporates the functionality of the Scrum meetings but with the addition of discussing whether one projects current or future sprint (iteration) will interfere with another's.

Scrum daily meetings ensure the project teams understand what has been completed to date, what issues have developed and what will you do before the next Scrum meeting (Schwaber and Biddle, 2002).


Traditional project methodologies such as PRINCE2, to name one, work in solitude within an organisation, they compete for resources from departments and managers, and when multiple projects are running in traditional methodologies, the competition for resources intensifies. A program or portfolio manager is charged with overall control of the projects, but this is done through a prioritisation process; the project with the highest priority will receive the most resources, it moves down the line of projects. This can cause multiple projects going over budget, over time and multiple project failure.

Agile methodologies, for example, Scrum can be aligned to the running of multiple projects simultaneously through the use of communication, not just between the teams of the individual projects but also between the teams of multiple projects with the use of Daily meetings in project teams to the use of Scrum of Scrum meetings where the individual projects communicate to ensure that if one project is going to cause an issue for another project, this can be seen as early as possible and taken into consideration and planned for allowing for less budget overspend and less time completion failures, thus having a positive effect on overall multiple project success.

Links from this KA to other KAs

Managing Multiple Projects can be linked to Project Communication Management. The necessity of communication between multiple projects is foremost in Agile project methodologies, this is evident in Scrum Daily meetings and the Scrum of Scrum meetings, which the latter is used to ensure that any project's development that may affect another project's development is communicated and planned for.

Managing Multiple Projects can be linked to Collaboration Management (or partnership management) as the successful collaboration of the individual projects is a necessary as the individual teams in a project.


Cadle, J. & Yeates, D. (2004) Project management for information systems 4th edn. Financial Times Prentice

Gardiner, P.D. (2005) Project Management: A Strategic Planning Approach. Basingstoke: Palgrave MacMillan.

Kanban Board. [Online] Available at: http://blog.ecoreusa.com/2011/08/25/agile-introduction-basic-concepts/ [Accessed: 11 March, 2013]
Kano, N., Nobuhiku S., FumioT., Shinichi T. (1984). "Attractive quality and must-be quality”. Journal of the Japanese Society for Quality Control 14 (2): 39–48

Kerzner, H. (2013). Project Management: A Strategic Approach to Planning, Scheduling and Controlling. Pp 1084. 11th ed. New Jersey. Wiley.

Roberts, P. (2007). Guide to Project Management: Getting it Right and Achieving Lasting Benefit. The Economist, New Jersey. Wiley.

Schwaber, K. and Beedle, M. (2002) Agile Software Development with Scrum, Prentice Hall.

Zarnett, B. (2012). Running the Scrum-of-Scrums: Agile Program Management Scrum Alliance [Online] Available at:
http://www.scrumalliance.org/articles/408-running-the-scrumofscrums-agile-program-management [Accessed: 11 March, 2013]

External links

http://www.techrepublic.com/article/how-to-manage-multiple-it-projects/1061892 How to Manage Multiple IT Projects

http://www.hp.com/education/courses/he549s.html Course Overview for "Managing Multiple Projects" offered by HP (Hewlett Packard)