Teams often have different sources of demand for their services. This is fairly normal, but I often see some teams try to treat all types of demand the same and even route them through the same process. Although this might work for a little while, you’ll probably quickly realise that the work and demand is more nuanced than a “one size fits all” approach and you’ll need to find ways to better deal with each.
First, lets clarify what I mean by demand. Its really any request or need for the team to provide some kind of service to someone (it could be a customer, someone internal to you business or a partner / vendor relationship). As you can see, just understanding who is making the request can lead you to start to understand more deeply about the need and the level of expectation around it. Not all requests should be treated equally – for example, certain customer requests may take priority over those from other departments in your business.
Not all types of requests will be the same. For example, customers might have certain types of requests that relate to their current service, but you might have needs coming from internal product sources that need capabilities to expand the customer base that you can offer to. Often the source of the demand will also give you some information about the nature of the kind of request that is going to come into the team.
Another source of demand that is often forgotten is from within the team itself. There’s often some maintenance activities that allow the team to “keep the lights on” that will need to get done. Not doing so, will eventually lead to larger problems with customers and / or product management that you’ll need to deal with. Another source of internal demand is capacity for improvements that can be made to the system of work. Not all improvements are free and sometimes you need to allocate capacity for it. If you haven’t allocated capacity to this kind of demand, guess what, things are often not going to get better and you’ll continue to tread water.
Another problem comes from the squeaky wheel. You’ve probably all seen this before, where an outspoken person (whether they are a customer, internal or partner) makes so much noise that you allocate an inordinate amount of capacity for their demand just to keep them quiet. This is not always the best strategy, because by saying yes to the squeaky wheel, you’re impliedly saying no to other types of demand.
So, perhaps you have a product owner that is going to do all this for you. Great, you’ve now just created a single point of failure – what happens when they go on vacation for 4 weeks, what do you do then? The team delegated all of this responsibility out and don’t have any idea how to go about “prioritising” the work. If you do have a product owner role, they should really be making clear through systemic policies about which demand is valid and how much of each type of demand the team should take on. This includes which type of demand you should not take on – just because someone has requested it doesn’t necessarily mean you must do it. Here’s an example board that describes how to deal with different types of demand using WiP limits per swimlane:
Note how half the capacity is allocated to Product enhancements, and a quarter each to customer requests and maintenance and improvements. It’s clear the amount of capacity being allocated to each source of demand in this case – you can go even further and put more detailed policies into each swimlane’s “Next” queue to describe how items get pulled into the system.
It’s important to understand the different sources of demand because your team will have a finite capacity. Understanding how to distribute that capacity amongst the different types of requests will determine if you can service them and whether you can provide a service that is fit for each purpose. Being clear about the policies around the sources of demand will equip the team well for dealing with the different sources without the need for constant management intervention. If you want to learn more about discovering and dealing with different types of demand, come along to our Kanban System Design course to learn more.