Two Levels of (Agile) Planning

Almost all firms that I work with have at least two levels of planning.  I call them “high level” and “team level.”

 High Level

At the high level, project or product ideas come in.  Someone has to prioritize these opportunities initially, to see which ones make the cut.  Often this is formally done once a year (although not my recommendation).  Often a small group does this, sometimes it is called a committee.

Depending on the size of the organization, high level could be for the firm, the division, or for the department.

The committee considers the benefits, the costs and maybe other factors. Sometimes the benefits and costs are formally calculated, and sometimes they are just ‘discussed.’

Usually, the committee comes up with a 1 to N list of projects that should be done ‘soon’ (often this means in the next calendar year).

Some recommendations to make this more agile:

• Do it with greater frequency (eg, every month for the Top X projects)
• Expect the numbers to change over time
• Make the numbers explicit
• Do it as ‘team knowledge creation’
• Get feedback
• Consider how accurate it is, can become, and needs to be

Team Level

I believe every project should go through ‘release planning’ after it has been assigned to a Team.

The Team should do release planning ‘again’ (it is roughly like what the committee did, but more granular) for the following reasons:

• it is being done at a lower level of detail, on only high priority work
• time has past;  information will be added or change
• we have the ‘best’ people for project X (the best implementers, the best business stakeholders)
• the Team needs the detailed information
• it affects Team motivation
• it enables everyone on the extended Team to get on the same page

I recommend the results of the Team release planning be given as feedback to the committee.  The committee may have questions and may raise issues the Team neglected to consider.  More likely, the committee will learn more about how badly they mis-estimated or misunderstood the work.  This is useful feedback for them.  In any case, it may be information that enables them to make better decisions at their level.

 

« « Something Unexpected || Joe’s Agile Release Planning » »