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.


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.