I was problem-solving with a potential client the other day. They want to manage their project portfolio. They use Jira, so they think they can see everything everyone is doing. (I’m a little skeptical, but, okay.) They want to know how much the teams can do, so they can do capacity planning based on what the teams can do. (Red flag #1)
The worst part? They don’t have feature teams. They have component teams: front end, middleware, back end. You might, too. (Red flag #2)
Problem #1: They have a very large program, not a series of unrelated projects. They also have projects.
Problem #2: They want to use capacity planning, instead of flowing work through teams.
They are setting themselves up to optimize at the lowest level, instead of optimizing at the highest level of the organization.
If you read Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, you understand this problem. A program is a strategic collection of projects where the business value of the all of the projects is greater than any one of the projects itself. Each project has value. Yes. But all together, the program, has much more value. You have to consider the program has a whole.
Don’t Predict the Project Portfolio Based on Capacity
If you are considering doing capacity planning on what the teams can do based on their estimation or previous capacity, don’t do it.
First, you can’t possibly know based on previous data. Why? Because the teams are interconnected in interesting ways.
When you have component teams, not feature teams, their interdependencies are significant and unpredictable. Your ability to predict the future based on past velocity? Zero. Nada. Zilch.
This is legacy thinking from waterfall. Well, you can try to do it this way. But you will be wrong in many dimensions:
- You will make mistakes because of prediction based on estimation. Estimates are guesses. When you have teams using relative estimation, you have problems.
- Your estimates will be off because of the silent interdependencies that arise from component teams. No one can predict these if you have large stories, even if you do awesome program management. The larger the stories, the more your estimates are off. The longer the planning horizon, the more your estimates are off.
- You will miss all the great ideas for your project portfolio that arise from innovation that you can’t predict in advance. As the teams complete features, and as the product owners realize what the teams do, the teams and the product owners will have innovative ideas. You, the management team, want to be able to capitalize on this feedback.
It’s not that estimates are bad. It’s that estimates are off. The more teams you have, the less your estimates are normalized between teams. Your t-shirt sizes are not my Fibonacci numbers, are not that team’s swarming or mobbing. (It doesn’t matter if you have component teams or feature teams for this to be true.)
When you have component teams, you have the additional problem of not knowing how the interdependencies affect your estimates. Your estimates will be off, because no one’s estimates take the interdependencies into account.
You don’t want to normalize estimates among teams. You want to normalize story size. Once you make story size really small, it doesn’t matter what the estimates are.
When you make the story size really small, the product owners are in charge of the team’s capacity and release dates. Why? Because they are in charge of the backlogs and the roadmaps.
The more a program stops trying to estimate at the low level and uses small stories and manages interdependencies at the team level, the more the program has momentum.
The part where you gather all the projects? Do that part. You need to see all the work. Yes. that part works and helps the program see where they are going.
Use Value for the Project Portfolio
Okay, so you try to estimate the value of the features, epics, or themes in the roadmap of the project portfolio. Maybe you even use the cost of delay as Jutta and I suggest in Diving for Hidden Treasures: Finding the Real Value in Your Project Portfolio (yes, this book is still in progress). How will you know if you are correct?
You don’t. You see the demos the teams provide, and you reassess on a reasonable time basis. What’s reasonable? Not every week or two. Give the teams a chance to make progress. If people are multitasking, not more often than once every two months, or every quarter. They have to get to each project. Hint: stop the multitasking and you get tons more throughput.
| Reference: | Capacity Planning and the Project Portfolio from our JCG partner Johanna Rothman at the Managing Product Development blog. |
