Software Vision - Creating the Backlog

On the back of my last post. I've come up with an idea. My criteria for envisioning new systems:

• Each release should be take no longer than 3 months and deliver usable value
• The complete vision may take a number of releases to realise
  
• The system/product definition (backlog) should be owned by customer/marketing
• Customer/marketing should decide how much 'traction' is needed between releases

The last point may need some explaining. By traction, I mean the degree of organisational change required to support a release. In circumstances where organisational change is difficult, it may make sense to use a 'low gear' introducing small organisation changes between each release, providing more 'traction', and increasing the possibility that the organisational change will stick. Conversely if the going is good, then larger changes may be possible, allowing the end vision to be realised sooner.

The point here is that software vision is a skill, and the people responsible need training. So my bright idea is training for customers/marketing people on how to create a product backlog.

Agile development starts with the backlog. But what happens before that? Here is my suggestion:

• A new product idea (instigated by anyone)
• If idea meets some minimal criteria, it enters the project funnel
• Organisation use some criteria to decide which projects to fund and in what order
  
• Funded projects acquire a 'customer team'
• Customer team go through some training on creating 'product backlog'
• Customer team create first pass backlog
  
• Development team work with customer team to refine and realise backlog

I'm going to give some thought to the training and assistance 'product' teams need to envision a good product backlog (product definition). I will use the term 'product team' instead of customer team as it is consitent with 'Product backlog' and SCRUM.

Hopefully I can come up with some good guidelines.

Anyway watch this space.