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:
- 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).
- 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.
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 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).
- The only person who is ordering the list of issues for the sprint is the Product Owner.
- As a stakeholder to get your issues on the planning list, the only counterpart is the Product Owner.
- 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.