Tip #8. Portfolio Management and Prioritization in Agile

While Agile works well at team level, it is portfolio level and higher where things get difficult. There are multiple things that get in the way:

• External dependencies: frequently, there are agile and waterfall projects within the same company. If Agile does not provide the level of advance planning that waterfall project stakeholders are looking for, there is immediate frustration with agile teams' planning process.
• Business stakeholders: if agile is rolled out for technology teams, your business stakeholders will be puzzled when you tell them that the team commits to what they can deliver within iteration and they won't accept scope/milestone directives from the business. This may seem a huge disadvantage to the business because your business stakeholders have to commit to specific dates of delivery; they have to initiative marketing efforts well in advance, and predict their product financials.
• Managers: they are used to receiving your weekly reports, which you will send them at a regular basis  ("push" method in lean) rather than being invited to your demo's ("pull", according to lean terminology). It means now it is their initiative, and there is no external trigger that will help them keep in touch.
• Priorities: if your team or your group of teams works well when you deal with one product and your system dependencies are minimal, things get confusing when you scale. Now you have multiple business stakeholders (product managers, marketing specialists) that you deal with, multiple code bases you are touching with many more integration points and technical dependencies, and in addition, the visibility for your product is huge, so the number of stakeholders at your demo's is going up. This is a great problem to have, but how to deal with it?

How do you address these challenges? The best way is to build a solid portfolio of your features and expose a roadmap based on your release planning. What are the primary milestones you are planning to deliver at high level? What are the timelines associated with key functionality delivered? There are multiple templates available but my preference is either portfolio template if we are delivering a product line within one program, or a feature roadmap if the team is delivering against specific product objectives. Good samples of these templates are available here. Many agile management tools such as Jira and Rally provide portfolio functionality based on the epics and user stories planned within your product backlog and generate roadmaps automatically or using plugins.

Once you create such a draft, the next step us to get input from the stakeholders based on shared priorities. Let them have focused conversations so that everyone understands dependencies and priority of one feature over another. Once the decision is made by the Product Owner based on this input, there is time to socialize your portfolio roadmap and the product features that are going to be delivered. It is important to build shared understanding that the roadmap is aspirational and changes will happen, which will be immediately communicated to the stakeholders.

Core stakeholders and anyone who is interested (dependent or contributing) in the outcome are invited (and expected) to visit demo's every sprint. It is advisable to send summaries (what was delivered, which stories were missed, major impediments and how they are going to be addressed, summary of questions and suggestions from the stakeholders, etc.) to all key stakeholders after each demo because some of them may not be able to join. Normally these summaries are send by the Product Owner or uber Product Owner within the portfolio, but sometimes Scrum Masters are better positioned to send it out every sprint as a summary.

In sum, there are two secrets to a successful portfolio management:
- involved the right group of portfolio stakeholders in providing input into prioritization decisions;
- once the roadmaps are created by the Product Owner and the team based on this input and the team's release planning, they need to be broadly communicated with the understanding that these goals and milestones are aspirational in nature and will be changing as delivery is progressing (progressive elaboration).

It is important to promote this atmosphere of co-creation with your key stakeholders in building portfolio and feature roadmaps for your products and to ensure that the roadmaps are updated as soon as there is a change. This is one of the reasons to keep these artifacts high-level so that a printed version fits one page, and to keep these files in a shared repository or on the Intranet, so that the changes are immediately available to all stakeholders.

Your roadmaps are both your strategy and execution tools that you use for communication and alignment, which makes them important artefacts relevant for product owners and agile teams as well as a broad group of stakeholders. You cannot overcommunicate these artefacts.

The essence of my advice is: do not treat your portfolio prioritization and release planning as a responsibility, treat these efforts and related artefacts as a vehicle to communicate your product vision and strategy, and align on dependencies and  expectations with other teams and business groups.