Skip to content ↓ | Skip to navigation ↓

We know that Scrum provides an Agile software development methodology, but how does it support innovation?

The truth is that while Scrum provides the mechanism to react to the innovative ideas coming down from Product Management, via an ever changing prioritized backlog, incremental delivery, and frequent opportunity for customer feedback, it provides nothing explicitly to support proactive product innovation within an engineering organization.

In addition, while Scrum provides the mechanism for teams to identify process and practice innovations, through the Sprint Retrospective, there is no built in methodology for prioritizing this non-product work against the product work in the backlog.

Over the years I have found that engineering organizations are routinely confounded by these lackings of Scrum, and have seen several different methodologies to enable engineering led innovation flow.  My favorite is to build into your existing Scrum development process a bottom-up innovation feedback loop.

This feedback loop incorporates the Lean Startup concept of a build-measure-learn cycle in order to achieve the twin goals of rapid validation and failing fast.   Here’s how it works…

Commitment to invest in Innovation

To start with there must be a commitment to invest in innovation from the organization.  Innovation is not free, but if harnessed it can pay for itself through operating efficiencies and product improvements.

Google famously utilized a 70/20/10 innovation investment approach with its engineers, where 70% of time was spent working on core product development objectives, 20% of time on innovation around core products and 10% on any innovation idea an engineer wished to pursue.

Many organizations would balk at allocating that much capacity away from core product development and Google has since put more constraints on the approach, but the core principal has been widely adopted; allocate some percentage of engineering, every iteration, to innovation. 

Tracking the Innovation Backlog

Once this commitment has been made, track this innovation budget with time-boxed stories in the product backlog which will be executed each sprint.  Seed the stories with aspiration goals, not traditional acceptance criteria.  These goals can come from Product Management, discipline leaders within the engineering organization or the engineers themselves.

The point is that they represent clear visions of problems to be solved, not of solutions. The moment they start requiring acceptance criteria it’s no longer innovation, it’s product development.

Product Owners have the responsibility to weigh these innovation goals against one another when prioritizing the innovation backlog, but they do not get to defer the expenditure of the innovation budget in order to pursue project goals.  

Innovation Game

Incorporate into each sprint review an innovation game similar to the buy-a-feature game.  Allow time for the engineers to demonstrate their progress towards their innovation goals, gain feedback, and pitch to stakeholders why further investments in innovation in a certain area are valuable.

Attendees are then each given some hypothetical investment budget, say $5, and allowed to allocate that budget as they see fit towards incrementing any of innovation areas further.  The product owner uses the results of the game to re-prioritize the innovation backlog, throwing out the ideas that did not generate enough market interest and focusing the future expenditure of the innovation budget on those that did.

Side benefit, I’ve seen this activity motivate stakeholders, especially within the engineering organization, to attend sprint reviews more often in order to influence this process.

Sounds easy right?  Not so fast.  While this feedback loop provides the mechanism for innovation flow, the spigot still has to be turned on.  For that an organization needs to look deeply at its cultural makeup, to make sure that its actions demonstrate that it values creative thinking, experimentation and candid feedback.

Engineers have to trust that it’s ok to fail.  They also have to be enabled with the space, time, and tools required for innovative work.  Once established you may likely find that your innovation budget results in some of the highest ROI opportunities and engenders a closer partnership in product development between engineering and product management.


Related Articles:



picThe Executive’s Guide to the Top 20 Critical Security Controls

Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].


Title image courtesy of ShutterStock