Managing portfolio with roadmaps and teams

If you are working with teams, assign products or project to them and want to structure your planning process on a higher level, you might consider using a roadmap for your portfolio level (I use the term product equal to project).

To give product portfolio a sound basis you might use a roadmap to visualise the load factor of your teams. Just give every team its own lane and assign the planned products to the teams.

If you are doing this for the first time, you might wonder on how much products in parallel your teams are working. It is reasonable to think about the reduction of product multitasking to increase productivity.

For those products you are not sure if they are worth working on them yet, you have three choices:

  1. Keep them unassigned (unstaffed), but put them on the "should be considered soon for implementation list". Those products should be discussed in a portfolio meeting.
  2. Put them on a parking lot, if you do not want decide soon about the implementation but do not want to forget about them.
  3. Kill them, if you don't want to think about them in the future anymore or if they will never get the priority to get capacity.
This roadmap was created in Confluence (Wiki). It is an easy macro which comes with the standard product.

This roadmap was created in Confluence (Wiki). It is an easy macro which comes with the standard product.

Here comes a little more description about the used lanes in the roadmap:

The team lanes

Within the team lanes you assign products to the teams. As long as a team works and is planned on a given product no other product should interfere. I recommend you to set a work in process limit (wip limit) for each team. This should speed you up and reduce waste.


Each product which could not be staffed by a team stays unassigned. Unassigned indicates: you want to work on this product, but do not know how to stuff it yet. In future discussion these products might get development time.

Parking Lot

You've got a product which is interesting enough not to kill it but doesn't have the priority to be developed you put it on the parking lot. These products might be good opportunities but hard to realise in practice.


If you refuse to work on a product, kill it. This means throw it away. Do not bother yourself in the future with concerns or thoughts about this product.

If you decide about your product portfolio, share it. Communicate it and make it visible as much as you can. If you want alignment, people must know about your decisions and for sure you have to defend it against the drift of the daily business. You might provide guidance for people and create policies for them. If you want to read about an example, I recommend to read about "how an issue finds its way into development".

If you are working in a hierarchical organisation, management should support or communicate the decisions. If communication is not aligned chances are hight that your portfolio gets sacked. Or just to stick with Gojko Adzic:

If communication fails, everthing else is just painting the corps.



From the trenches: How an issue finds its way into development

This article covers strategic planning using a project portfolio approach and tactical planning including incident management. It's direct from the trenches of development and explains the involvement and planning between stakeholders and development teams.

To dig into it, we need to distinguish two levels of planning:

  1. The strategic level: priorities and roadmaps are planned here. Teams get allocated concerning these priorities. Usually we allocate one team one project at a time (wip limit equals one).
  2. The tactical level: iteration (sprint) planning is done here and we deal with urgent issues from projects which are not allocated (lower priorities). Iterations follow goals of the project which is currently in progress.

As said: we are working under the constraint of "avoid multi-tasking", so each teams only works on one product/project at a time (iteration/sprint).

Stakeholders of an allocated project are are fine, because they are on the development track. If the project is not allocated, stakeholders only have chance of capacity if the issues do not clash with the overall priorities from management. The best thing a stakeholder can do is to plan the issues two weeks ahead of each sprint, so that there is time to break down the requests to get them into the sprint planning during the tactical planning and align them with the overall goals and priorities.

Strategic level

Planning on strategic level means managing priorities on product or project level. This is done with the management and Product Owner team. The result of this planning is an allocation of each an product/project to a team over a given period of time. Other projects keep unassinged and others might be suspended on a waiting list (parking lot) or killed (won't ever be done). 

We use a roadmap for planning and communicating the plan.

The allocation implies the priority. Allocated projects are those ones under development or planned for development. Unassigned are those ones which will be discussed next time and are more likely to get development time, parking lot means that this project is out of development scope and killed projects are entirely removed from priorizaton process.

The strategic planning is an reoccurring meeting - at least every six weeks. 

Tactical level

Tactical planning is about which issues should be done in wich sprint and dealing with change and other (external) effects. This is where reality hits. Yes, there might be requests from not allocated projects like bugs or small improvements. Its the duty of the Product Owner to deal with this requests and not to violate the given priorities from management. Usually most requests are urgent, but not very important, so it is possible to defer those to avoid time slippage of the important project priorities. 

Planning and timing

During development we are working with sprints, which are iterations of two weeks. The scope of those two weeks is mainly fixed because we are focusing a goal. The planning of all issues happens during the first day of the sprint. So if a stakeholder is late with communicating his requests, chances are low that your issue will get important enough to switch scope with an already planned issue.

To avoid that and increase the chance to get those issues planned is easy: be on time. This means stakeholder need to communicate their issues at least one week before each sprint (depending on size of the issue), so that the team is able to refine the issues (break it down, get it ready, get it understood).


  1. The only person who is ordering the list of issues for the sprint is the Product Owner.
  2. As a stakeholder to get your issues on the planning list, the only counterpart is the Product Owner.
  3. Talking to development team members is about clarification, not planning. Stakeholders should not waste their time trying to sneak into a sprint. This only creates waste and delay.


What's your organisational default? Stay or leave?

There is a joke I'd like to tell:

>> CTO and CFO are talking about their staff.

CFO: "Imagine, if we educate them and they leave."

CTO: "Imagine, if we do not educate them and they stay." <<


I like that one, because it easily shows a big conflict in organizations.

Whenever I am thinking about this joke I am asking myself: What is the default in the organisation? Do people stay or leave? And furthermore:

Why do good people leave?

Usually good people leave, if you do not educate them or if they don't work in an educated environment. Both is interdependent and depends on each other. Both is closely connected to intrinsic motivators like status, certainty, autonomy, relatedness and fairness (scarf).

Educated people

If you educate people you raise their status, because people are feeling good in self-development. On the other hand, if the skill of those people is at the mercy of a jackass who has no idea, but gives instructions, people are feeling threatened. They feel less important which is a drop in their status.

Take this example and inspect from the perspective of fairness and autonomy. I guess you will easily find more social threats and opportunities. Reflect about your organisation: How do we educate people, so that they would like to stay?  

Educated environment

An educated environment gives people certainty and autonomy. Both is a reward for people which increases ability of complex problem solving and minimises social threat. An educated environment gives power to the people and power usually is information. Information produces certainty and enables autonomy.

It increases certainty, because people are able to predict behaviour of others, which minimises social threat. Moreover people are more certain about their near future. To be able to predict the near future is very important, because our brain is forecasting all the time. In an unstable environment we loose too much capacity in relation to this function. It is simple: People are overwhelmed with concerns in an uncertain environment - they don't like to feel insecure, don't you?

Frascati Rugby by f/orme taken from Flikr is licensed under CC BY 2.0

Frascati Rugby by f/orme taken from Flikr is licensed under CC BY 2.0

If you grant autonomy you have to buy it with information and trust. You will earn cheap decision making and self-confident people. Think about the last jackass who made your decision. Did mean a threat to you? Did your inner voice say: Once again and I will... quit? Overruled people will never be responsible nor will they stay for long. 

To me, relatedness is another aspect of an educated environment. People like to work with others they know. They like most working with people they like, but working with strangers is perceived as a threat. Mixing people frequently around and assigning them to new "teams" is a threat to people. Again, they do not feel safe and get annoyed and angry.

Constantly loosing connections is an high attractor to change the workplace because of a drop in relatedness, fairness, autonomy and status.

My perspective

I think there is a lot of benefit if in self-reflection about threat, social interaction concerning education and environment. But to me real value lies in an educated environment, because everybody is searching for that kind of environment. But it is rarely out there.

The biggest struggle is how to create it. First steps might be an economic framework for teams, a clear set of rules and regulations concerning decision making and a shift of decision making from management to people. Information should be no longer a currency of a few, it should be the budget of the whole organisation shared between each other. Management should provide as much information as possible to enable decision making. People should get feedback about their decisions, there should be open discussions without status threat. Transparency could be used as a tool to share information.

While everybody is searching for an environment where safety and relatedness isn't "words on the wall", you could step forward to create it. Be humble, be brave! 


Title picture "Church Knights Templar in Chwarszczany (Quartschen), Poland" by Jan Jerszyński (Own work) is licensed under CC-BY-SA-2.5, via Wikimedia Commons


Learn as you go - A scientific method

Are you stuck in defined industrial processes, lined up in dependencies while working on an undetermined goal? Do you need to try out what works and what does not because your goals are too fuzzy? Do you need to learn as you go to prove your theory with data?

Then you might try a scientific method.

Observations in science. By Marretao22 (Own work) [Public domain], via Wikimedia Commons

In science you do experiments. This means you observe something, then you make a guess about it and formulate a hypothesis. To prove your ideas you experiment and see if you can validate your ideas - you gather data: hits and no-hits. If it sticks, you keep it - if not you formulate another hypothesis, experiment and observe the result again. It is like: "Oh, the apple falls to the ground. If I toss a stone, it will fall to the ground. Toss the stone. Yes, stone falls to ground."

So a scientific method works like this: Observation, hypothesis, experiment and back to observation - closing the cycle in iterations. 


Observation is the start and endpoint of any experiment. You gather insights toward your work and the decisions which were made from the data you have collected. You measure, interview and study the work you are doing or the experiment you have done.


Once you observed the environment you want to improve you assume what might be the next right step to follow. Formulate it and set it as a goal. This kind of goals are rather fuzzy than predictable. Your goal needs to be proved. So you stop talking and start doing.


Experiments are about exploring your ideas. Nothing is perfect from the start, so you have to gather insights. You start with an idea of what the world could be and check out  how wrong and right you are. Important insights are discovered after the start. Exploring is like: Build, break it, build it again and tweak it - that's the way solutions are discovered.


Use small iterations to experiment different hypothesis. Adjust your hypothesis as soon as you got real data and reiterate to your goal. Go for fast feedback from your customers and users to generate insights. 

If you are looking for this kind of approach: Agile, e. g. Scrum uses this scientific approach.


How to scale definition of done - When to do what?

A common question about definition of done is - "When should we do which activity?" A definition of done is usually about:

  • Done when the story is done
  • Done when the sprint is done
  • Done when the release is done

Usually you should strive to be done as soon as possible with the most activities, so do the most stuff at story level except there is a reason not do.  Here are several why you might scale your activity from story level to sprint or even release level.

Transaction costs, synergy or no demand

The result of adjusting focal distance while taking the picture. By  B166ER at the German language Wikipedia GFDL or CC-BY-SA-3.0, via Wikimedia Commons

Some activities should be done for all stories and it is cheaper to execute them together, usually activities for non functional requirements fit here. Take for example performance testing or testing with data from live systems. If you do it once a sprint it might be enough. Moreover, there are different opinions about how much e. g. security is required per story, this happens per stakeholder. Sometimes there might be no demand to do the activity per story.

Minimum viable product and experiment

Sometimes you want to experiment functionality. You develop it without making things nice and layout it the way it fits into the GUI design. This approach is fairly okay, because you want feedback, you wanted to test your idea. This is often when you go for a minimum valuable product. You might run a few sprints with making it run and before the release, after you said - "this is it" - you make it nice and fast. 

Low performance, too many restrictions or impatient stakeholders or customers

If you spent too much time with developing one story and you cannot get enough features done. Then you might suspend some activities for later. This is also recommendable if you've got impatient stakeholders or customers. Show that it works and then make it nice and fast.



Transparency - Sure you can deal with it?

Enterprise, you want to go agile - sure you want?

If you honestly do so, ask yourself, as somebody in charge, the question: "Can we handle the effects of transparency?"

Then split the we and insert instead:

Management, people and culture

The effects of transparency spread wide but are deeply routed in your corporate culture. It is about how you deal with problems: Will you welcome them, will you deny them or even worse will you surrender saying: "That is like the way it works - accept it." 

Furthermore it is about how long will it take to solve problems and when does frustration start how will your people deal with it? Key question still is: will you be able to learn how to improve fast enough, before your system gets to annoyed of transparency?

Some questions to sting yourself

By ZooFari (Own work) CC-BY-SA-3.0, via Wikimedia Commons

  • The unsolvable problems will be addressed - will you spend the time and effort in making the impossible possible?
  • Will you take every problem serious that will be addressed?
  • How patient is the culture of your organisation?
  • How long will people wait before they get annoyed by all the problems perceivable?
  • What if your people are stuck, will they solve problems on their own? 
  • What if people are stuck and get frustrated about the amount of problems every day? 
  • What if your people fear or realize that they archive too little?
  • How will your culture handle and react when problems are addressed?
  • How will you react if people are part of the problem? 
  • What if you as a manager are part of the problem? 
  • Are your people comfortable being naked in business? 

There is a lot more to ask, but if you do feel uncomfortable with this rethink your intend about an agile transition. If you do say, transparency is no problem at all, then you might have a great organisation or you've lost touch with the culture of your organisation. 

The only thing I can highly recommend is: Go to the people who work, get firsthand awareness about how work is really done, ask for the problems and get a keen appreciation about improvements. Be humble and help them!


read it in German: click

Ready ready* for the hammer

Some time ago I've read lamentations about story readiness and why is it bad because of it is destroying the intent of user stories. First I was amused, later on I was afraid that people will take this for sure. I do recognize that there is truth in this post, so far that people still miss using conversation - direct face to face conversation - and sometimes the concept of story readyness is taken for specifying user stories too far in advance and detail. Let me revisit this statement later on.

What is story readiness?

Story readiness is an artefact of the team. It is a contract and a visualisation about the what the team needs before starting in order to deliver working software within a sprint. First of all it is an activity: The team decides what parts are essential to work before starting it: "what should we collect to work on stories in a flow state, okay let's write it down." Now the teams knows the important parts to collect within their environment and this is the most important part of it - knowledge and visualisation as baseline for improvement. Using this artefact and sharing it with the other stakeholders is an act of fairness: We show you what we need to start (sure not everybody is interested in, but this is not the point). 

Now we've made the rules and circumstances explicit, we know as a team what to ask, what is important to us, what are the cornerstones we have to get clear. The performance of any team is in exponentially proportional dependency to the state of the work you start and you should start the ready work. Using story readiness as a contract between product owner and team means you declare a last line of defence to deny work wich is not ready for development.

Revisiting it

The intent of a user story is face to face conversation about the why, the whereof the story. Story readiness deals with what should we talk about to get the story ready, what has to be in place, so that you can start. If you do not know what you need to talk about, the conversation might get cumbersome. As said an user story conversation is about the value the story should provide and a discussion about different ways of implementation the function part. Even if this happend perfectly, the team is all fine with the intention of the user story, defined functionality and everything they need to get the story done. What if the parts the team needs from outside of their circle won't be delivered in time? What if the last line of defence is breached, because the team took unready work into a sprint and is blocked - well you had a nice conversation, but still important stuff is missing and work won't get done.

A definition of ready is a tool to be used. For sure teams with a classic requirement engineering background tend to do much requirement engineering in advance than agile style, this might lead to waste, but not definitely. Sure a team might not feel responsible for making the work ready, then you might use the readiness to check what the team thinks it can contribute and work on the items which they do not consider under their influence. As a scrum master you got a nice tool to show your team and management where improvements can happen.

Still you as a team are responsible to get the work ready, you might use the story readiness as a contribution to your last line of defence, to deny work which is not ready for implementation and tends to block your delivery within your sprint.



By Photographer''' Isabelle Grosjean ZACC-BY-2.5, via Wikimedia Commons

"If I had a hammer and hit me on the hand - would I say damn this shit should be banned?

If I had a hammer and something hit my hand - would I say damn shit the hammer should be banned?

If I had no hammer and something hit my hand - would I say damn I need a hammer to be banned?

If I had no hammer and nothing hit my hand - would I say damn shit nothing can be banned?" 



PS: *Ready ready is a term borrowed from Jakobsen and Sutherland, "Scrum and CMMI - Going from Good to Great: Are you Ready-Ready to be Done-Done," 2009


Definition of ready - Your sword in the shield wall

The definition

A definition of ready is used to produce story readiness. A story which is ready for development needs to meet criteria. Thus criteria defined is required to accomplish a story. The definition of ready is an activity of the development team to state everything what's required before development begins. It is also a contract between development team, product owner and stakeholders. A development team has to contribute that the criteria is meet as far as possible. If criteria is missing from stakeholders or product owner the team should deny to start the work or close the gaps with own decisions and suggestions. The definition of ready is a tool to make explicit and transparent what is needed to start a story and can be used for developers as last line of defence.

The sprint

The goal of a sprint is to deliver working software in the state of done. The delivery is called potential shippable product increment also known as usable software ready for installation.

The battleground

To deliver a full working software due to your definition of done there are preconditions to be met before you can start your work. E. g. you might need several documents in advance like text, math and formulas, design and so on. On the other hand you as a development team need to specify which criteria has to be met to validate that you build the right software.

The battle and the sword

A Seax photographed by Bullenwächter, GFDL or CC-BY-SA-3.0, via Wikimedia Commons

In order to complete a story within a sprint every part of the story must be delivered in time, otherwise the team might be wasting time with waiting during a sprint, will not deliver or will have to adjust the delivery later on. Furthermore, to avoid waste of specifying stories too early the timeframe of making work ready is set very close to development. To dissolve those contrary interests - that is the battle. Like in a shield wall you have to push forward and should not loose ground.

Cutting through dependencies in a tight schedule between preparing the work and implementing it is tough. On the one side you shield yourself against getting blocked and deny work which is not ready for action, on the other side you have to contribute to get the work ready and must be aware what is required to start. Both sides are the cutting edges of your sword. 



Different projects in a sprint - Juggling with knives

There is often the question: Different projects in a sprint - does it work? The answer is either yes or no! 

Yes, it works

When you use sprints, you might use Scrum. Scrum is a framework. You take it and put the work in that frame a sprint is offering you. Once your work is in that frame, you can work on it, no matter if it you are delivering for one project or serveral. You might loose focus because the projects are tearing you apart, but as long as you are able to stabilise the priority of you work during your iteration there is chance to succeed. And you still got a ScrumMaster to support you.

No, it does not work

By David Shankbone (David Shankbone (own work)) CC-BY-2.5, via Wikimedia Commons

It will not work, if you do not put all of your work into that frame. Leaving work out of your sprint will lead to distraction and waste. Usually while there is work happening outside that is pulling your attention, this work is not weighted against the work in your sprint. There will be waste through discussions about priority and unfinished work to resume. On the other hand when there is to much ad-hoc work you will run into trouble too. Ad-hoc work is similar to work which is not framed - and yet a little bit different. A sprint is also under policy: do not disturb the people working. If your workplace produces too much ad-hoc work the process you've selected will be under constant need of maintainance, so the system will need other desire paths than your process might provide, unable to heal itself.

There is still hope

You can learn about your environment and work situation. Just make your work visible, put your work on a taskboard and follow its flow from introduction to done. Visualize the problems and impediments you encounter and improve around all mistakes that happen. It might be a hard road and it is worth it. Usually this is true: "Only what is visible can be improved."

Different projects in a sprint - it's like juggling with knives, it might work or it might hurt... 


A self healing system - Desire paths

A self healing system

We are good at setting standards, but do we take them as a baseline for improvement or do we end up in bureaucracy? Standardization means automation. We take our insights and wire them to procedures. Step 1 followed by step 2 in exactly the order we prescribed: entirely deterministic, but perfect?

What about when we are all wrong? What about if we build up a wrong standard? Good for us, but useless for our customers? What if they desire another path, perfectly sane, but our system does not provide it? Should we keep it with: "We are sorry, this action is not provided"?

Parks in Finland

In Finland, planners are known to visit their parks immediately after the first snowfall, when the existing paths are not visible. People naturally choose desire lines, which are then clearly indicated by their footprints and can be used to guide the routing of new purpose built paths.  (Desire path, Wikipedia, 19th of June 2013)

A desire path (right) merges with a footpath (center) in Helsinki, Finland (Wikipedia)

Wrong standards are business bugs. Get over it! They do not meet customer needs, instead they show an opportunity to learn or worse - your ignorance.

So what to do now?

Automate less complex, learn from existing data, ask your frontline staff.

Automate less complex

Da Vinci said: "Simplicity is the ultimate form of sophistication." So if you automate a process, simplify it first. Do not blindly automate everything, question it. Prefer an simple implementation over one with lots of different scenarios. A simple scenario can go for itself - they can be healed, complex scenarios tend to be waste and difficult to use and exclude everything which was not considered by its builders.

Reconsider automation of systems with a lot of ad-hoc-racy. Determinism might lead to a lot of maintainance of the automation you want to provide. 

Learn from existing data

You always got data - learn from it. Have a look at which way data is used, what behaviour is associated to it? What does surprise you while looking at it? What is fascinating? What interesting? Learn from the real world. Iterate, prototype, gather feedback from customers. You got no contact to them - step out of the door, insights are waiting:

"You step onto the road, and if you don't keep your feet, there's no knowing where you might be swept off to." (Lord of the rings, Tolkien) 

Ask your frontline staff

Whenever you have touchpoints within your service, you will have frontline staff who is in close contact with customers. These people know the paths who are unable to go and cannot be healed within the system. 


Sprint Planning - The last line of defence

How to enter a development bastion?

Still teams get stucked because the requirements they work on are not ready for development, because questions have not been asked, key questions not been answered, stakeholders not involved and the most ugly part: decisions not been made. So a lot of teams have to start with rather poor sprint backlogs.

To be productive and have fun with your work, you want no distraction from you work. You usually don't like to be blocked because of poor decisions or no decisions at all. As a developer you are standing in the last line of defence, because if nobody decides, you will make the decisions. 


"In a fortification with bastions, the citadel is the strongest part of the system, sometimes well inside the outer walls and bastions, but often forming part of the outer wall for the sake of economy. It is positioned to be the last line of defence should the enemy breach the other components of the fortification system." (Wikipedia)

In the shield wall

Ivar’s shield wall had held, but I could well imagine the ferocity of that battle.
— The Burning Land, Bernhard Cornwell

Standing there in the last line of defence you as a developer take it as a bastion to defend your sprint from distraction and blockades. Ask questions, demand decisions, make decisions, share your insights and if planned work is poor, then reject unclear requirements or stories. 

Sprint planning is a tool to be used. On the one hand it is about telling stories to get a common picture or to plan your collaboration, on the other hand you might use it as a shield to protect your performance. If you use sprint planning als shield and sword, then you show that there is a responsibility about making work ready. Remember you are involved in making work ready and you have to play your part.

You might try to add some components right in front your last line of defence:

  • Try to get stories small, because small stories are easier to understand.
  • Get stories ready for development for about 1 or 3 weeks before a sprint.
  • Use estimation or grooming sessions to ask key questions. Remind people about your questions constantly (as a scrum master, be a mosquito).
  • Make teams cross-functional or involve the people who can provide information. 
  • Write down the essential parts of your stories which need to be solved before (make it explicit and visible). This might result in a definition of ready.
  • Reject stories in the sprint planning, to show that essential parts of your stories are missing (do that in a responsible manner). 
  • Visualize at a wall which stories are ready for development. A product owner might suggest, but the team decides.