When people start to set up a Portfolio Kanban to manage their portfolio, there is often a step where we need to determine how we bring in ideas, and have we then control the flow of those ideas as we evaluate whether we want to do something, or not. We have probably identified a group of people that are the Lean Portfolio Management (LPM, SAFe term, but lets face it there are equivalent groups everywhere). Problem we have is:

• We need to set up mechanism by which random ideas (those in the Funnel) take their first step and get into the WIP limited “Reviewing” column (see https://www.scaledagileframework.com/portfolio-kanban/ for basic discussion here - your Kanban board might be different, but the problem of going to the first step in the board is probably the same).
• We need to do this understanding that our LPM meetings are going to have remote participants in many cases.
• We need to make sure the funnel doesn’t just get huge requiring constant re-visiting, re-viewing, and so on, creating additional work just because we are managing a huge list.
• We need to communicate quickly / transparently what is going to happen with the request to manage stakeholder (requestor) expectations.
• We need to make it easy for anyone with a good idea to contribute that idea.
• We need to make it easy for leadership to propose ideas, but to also establish a level playing field for LPM to work items and be clear about our expectations of them.

What this means is that we need to set up working agreements around the LPM on how we will process this step. One approach is to use the “Bun Protocol”, perhaps with some specific email conventions, to address. Basic approach is:

• Request comes to member of LPM. I am thinking that we publish a list of LPM members, or some specific subset of the LPM. We describe the minimal requirements for a “funnel” item. We don’t expect them to create an entry in the portfolio management tool, but we say that if you want have a request or an idea, you should draft an email with that information, create a subject that is prefixed with “PORTFOLIO IDEA” (for example), and then select a specific LPM member to send it to, and send it to them.
• The LPM member is considered to be the “owner” of the request now and remains the owner until is someone else takes the request on or we decide not to proceed. Once the LPM member gets the request they should (at a minimum) review the information with whoever sent it in and create / update a record the portfolio management tool that represents this funnel item. The record will include “date created” so we can track the age of the request and how long it has been in the “Funnel” column.
• The LPM member now has a choice:
  • They could decide that this item has no chance to get to “Reviewing”, given all the other priorities, and so informs the requestor that the item is closed.
  • They decide that they should not be the champion for the request (limited expertise, capacity, whatever) and so works to do a “warm handoff” to another LPM member (perhaps this is done in email through another convention so we can continue to work remotely). Again the requestor is informed.
  • They decide that this item should be considered for the “Reviewing column”. At the next LPM meeting and based on the WIP limit of the “Reviewing” column the LPM determines which items are best to bring into Reviewing. I expect that there will be socialization of the idea prior to the LPM meeting, with people beginning to understand who item is for, what it is, why it is important, etc but I do not expect a formal process for this. I expect that the LPM “owner” will properly represent the items they currently own in that meeting, perhaps even bringing in the original requestor to help represent the need.
• Once the “Reviewing” column is filled, we need to do an aggressive triage of the remaining items in the Funnel column. I think we should establish a rule like “if its been in Funnel for 6 months, then we close it” or if we feel like we can’t close it, then give it a status (eg “the attic” – a special class of “done”) that basically means we don’t look at it again. For items that we close (or put into the attic), we need to get back to the requestor and inform them.

With working agreements like this, we end up with an average initial review time for new funnel ideas of about 2 weeks (assuming LPM meeting every month). If we use the 6 month idea, average lead time overall for disposition of any new funnel items is about 3 months. Pretty good, I think. This could form the basis of service level agreement for various stakeholders (eg ITOP, customer projects, our own Trains, etc).

• We might not need to create a request if the LPM member believes this idea has no chance of getting to reviewing stage but I suspect that for now we just create relevant records until we become more smooth – better transparent and visible than not.
• We want to establish a “pull” system for LPM work. There is one “push” part where the requestor sends work to an LPM member, but after that it is a pull, and sets a precedent about how the rest of the Kanban board will operate.
• The idea that we close / delete items that have been around for some period of time usually scares people, hence the “attic” idea (which doesn’t delete the item – just makes it invisible). I think we need to be clear about items we are unable to start.
• The thinking behind the age criteria is as follows: There is a high probability that something that “did not make the cut” this time will also “not make the cut” next time. The business has moved on and there are always high priority items coming in. So, this idea that we had has not seemed to be so important in comparison to other ideas that we have not started work on it for 6 months. Based on this evidence is there any reason to think that this idea will be more important than future ideas. We should therefore not pretend that we are going to work this and stop revisiting this item over and over again.
• BTW if the idea does turn out to be important, trust me, it will come back

• “Bun Protocol”: This is a general protocol to help people deal efficently with requests. Idea is simply, lean, etc.