Introducing Innovation Story Walls

An excellent and inexpensive tool for developing innovations where you work is using Innovation Story Walls. The scope of this blog topic is to offer some ideas on how you could and should implement these story walls. Many of us already know innovation makes a difference. It’s the:


• Key to survival and growth for all companies around the world,

• One of the highest sources of value creation,

• Diversity of ideas and sources of ideas that makes this so valuable, and it’s

• Typically a bottom-up phenomenon.

This has been proven over and over again in published research journals over the years, and this is our opportunity to expand on the innovations already identified via the Eureka portal.



No one, just because their role or has the market cornered on innovative ideas. The reality is that innovative ideas can come from anywhere and a lot of companies are recognizing that. It’s all about collaboration to crate new ideas because:

• Sometimes somebody has a great concept idea but no idea how to get from ‘here’ to ‘there’,

• Sometimes somebody has an idea to contribute that will help take a good idea and make it a better one but isn’t necessarily certain how to offer or contribute that idea,

• Sometimes somebody is shy about the concept idea they have or adding their 2¢, and

• Sometimes somebody has an idea how to get from ‘here’ to ‘there’ and just wants to open it up to others to make it more complete by offering any ideas they haven’t though of yet.


Now to the meat of this post ---

1) The objective of this tool is to (at a concept overview level):

• Publicizing what you’ve done , and

• Publicizing what you’d like to get done

It’s the latter of these two we’re interested in this post.

~ AND ~

2) Determine:

• What prerequisites people believe need to exist to implement the above and make it successful . . . .

• From and for managers and the leadership team(s) and

• From and for everyone else too

• What governing rules or constraints do you want in place? – i.e.

• Are anonymous story cards acceptable?

• Can people move or remove story cards that already exist?

• Do people want to use thread or strings to tie strong cards together or how will you string story cards together into a complete story?

• etc

• Where should innovation idea themes come from or should we have any at all?

• Should there be a maximum number of innovation ideas on the board at any one time?

• How do innovation opportunities can be added? – i.e.

• Should there be a spot on the wall for ideas in queue?

• What is the maximum time an innovation opportunity will remain up on the board and active . . . .

• Before it’s nullified / rejected,

• Before it’s formalized, or

• Before it’s removed due to inactivity

• Do you want to score ideas based on interest factor or some other criteria?

• Where the physical placement of the story boards should be in the workplace

• Which group(s) should govern this activity – i.e. who do people go to if they have questions?

• Who transposes the story cards into some on-line form or whatever before they are removed from the wall?

• Etc.


Need more convincing?

Two good, on-line articles on this topic are available at:

• http://www.forbes.com/sites/work-in-progress/2011/04/01/how-to-tear-down-the-walls-to-business-innovation/

• http://www.cognizant.com/business-consulting/Site%20Documents/fourwalls%20exec-sum.pdf

Classes or Categories of User Stories

Please see below. I couldn't easily find a site that has all of these definitions together in one spot. 

Epics 

Epics are large user stories, typically ones which are too big to implement in a single iteration and therefore need to be chunked into smaller user stories at some point before the effort required to complete them can be reasonably estimated. 

Themes 

A theme is a collection of related user stories.  For example, for a university registration system there might be themes around students, course management, transcript generation, grade administration, financial processing. 

Themes are often used to organize stories into releases or to organize them so that various subteams can work on them.   

Spikes 

The purpose of a spike is “to figure out answers to tough technical or design problems”. Spikes are considered useful when a more accurate time (and cost) estimate is required for an upcoming piece of work. 

Foundation development, investigation work and the set-up of a lab environment so it's ready for use when a software build becomes available for testing are all good examples of spikes. 

User Stories 

A user story is a high-level definition of a requirement, containing just enough information so that the developers and testers can produce a reasonable estimate of the effort, potential risks, key complexities, etc that need to be considered and are required to implement it. 

Tasks 

Tasks are single units of work such as checking out a code branch or installing a build in a test lab. 


Would you like this elaborated upon further? Just let me know.