Innovation within a Scrum Team
The focus of this article is on one of the most important things giving lifeblood to the Product Backlog and promoting its characteristic of long-living artifact, the Innovation.
The innovation allows us to shift from a Project perspective, by which a project is limited in duration, to a Product perspective, with a product evolving over time.
We’ll then discover the importance of quality as an enabling factor for the innovation and how innovation can be measured throughout the sprints, by also indicating some of the practices that could be used to let it flourish.
When is the right time to think about innovation for a Scrum Team?
That’s a question I got several times during the trainings I had the pleasure to deliver.
Well…the short answer is every occasion can be the right one!
As a Product Owner, having innovation within your product can lead to a rapid validation of your hypothesis and, consequently, the possibility to give more value to this, knocking down unrealized value.
But is it always possible to do innovation within a Sprint?
It depends on you and on how much quality your product has…
Why Quality is related to Innovation?
One of Scrum Team’s objectives is to focus on delivering high quality product increments.
More quality your product has, less time is spent on maintenance stuff, so more time is saved to give vent to your creativity on innovation.
There are two metrics from Evidence-based management (EBM) Ability-To-Innovate Area, that are related to each other and help us to understand how much is spent on innovation and on code maintenance throughout the sprints:
- innovation rate: the percentage of budget spent on innovation
- technical debt: the technical debt we’re accumulating (and that we need to reduce through activities like bug-fixing, or refactoring)
By the end of each sprint, we can check how many Done items of the Sprint Backlog were related to innovation (to obtain that, if asked, I usually suggest the Scrum Team to ‘mark’ them with a label, to easily gather the information from some tools like Jira), so that we can create an Innovation Trend diagram.
This diagram gives us an overview of the percentage of budget spent on innovation (you can obtain that from story points’percentage of Done innovation items within the sprint) and, at the same time, you could conclude even if it’s the case to refill the product backlog with new fresh ideas, unless product’s unrealized value is very low. The remaining budget is then spent in maintenance and expansion of already delivered features (these trends could also be indicated within the above diagram to let it be more exhaustive for an overview of the whole budget spent in a sprint).
Which are some of the practices helping us doing Innovation?
Of course there are several practices, also according to specific approaches you’re going to use.
For instance, there are some frameworks focusing on dedicated periods of time for doing innovation – have you ever heard about Design or Innovation Sprints?
Without entering deeply in one or another approach, I’d prefer to focus on some practices that can be used whenever the Scrum Team deems appropriate, as a self-organized team, without impacting on the structure of a Sprint (by Scrum Guide, all the Sprints have the same characteristics) and that gave me a great support for my experiences:
- end-users observation, while they’re interacting with the product
- customer or end-users satisfaction surveys
- development team’s ideas (don’t underestimate this point!)
- stakeholders’ feedback during the sprint reviews, or other occasions of interaction with the Scrum Team
So what?
As a Product Owner, let’s be open to insights and suggestions and try to maximize the occasions for inspection and adaptation of our product.
The more frequent these occasions, the more we are able to validate our assumptions and product’s realization becomes an increasingly exciting game!