Are there any brainstorming techniques related to requirement gathering sessions or Sprint Reviews that can help produce ideas?

Question

Adding creativity techniques to Scrum product planning

I'm evaluating some creativity techniques to produce ideas/solve problems, whether they could have a benefit in Scrum or not. Specifically, I'm looking at the process where the Product Owner and Customer collaborate on software requirements at the beginning and the Sprint Review at the end.

My question is: Are there any techniques related to the requirement sessions or Sprint Reviews which can help produce ideas? Are ideas important for these sessions?

Answer 1

Before You choose some technique You should define criteria: do You need go wider or deeper?

Probably the best strategy is:

• at the beginning is to go deeper (focus) to gain best understanding what really are Customer needs,
• later, at the end - go wider to show the full possible spectrum of possible sullutions

For doing that You need understand specifics of different [thinking techniques].

IMHO You should apply accordingly to steps mentioned above:

1. Morphological analysis
2. [TRIZ][3] techniques combination: System Operator aka 9 windows & Ideal Final Result (IFR)

p.s. unfortunately can't provide more links

Answer 2

TL;DR

Determining what product should be built, and what features the product should have, is the responsibility of stakeholders identified in a project's charter. It is never the responsibility of the Product Owner as defined by the Scrum framework.

Generating Business Ideas Isn't Product Owner's Responsibility

Are there any techniques related to the requirement sessions or Reviews which can help produce ideas? Are ideas important for these sessions?

This seems to be a fundamental misunderstanding about the roles of the Product Owner and the stakeholders in Scrum. The Product Owner is not there to help stakeholders come up with business ideas; the PO role is there to:

1. Elicit product requirements from the stakeholders.
2. Build consensus among stakeholders about the value proposition and priorities of product features.
3. Work with stakeholders to formalize an ordinal list of features to create a sequential Product Backlog.

None of these things amount to brainstorming about potential product features. That is the responsibility of the stakeholders and executive sponsors of the Project Charter.

Scrum Guide Isn't Prescriptive About Soliciting Stakeholder Input

The Scrum Guide is not prescriptive about how the Product Owner should interact with stakeholders, but it is clear about limiting responsibility for the Product Backlog to the Product Owner. Formally, the Product Owner role is defined within the framework as the sole arbiter of the Product Backlog and the sole representative of any stakeholders in the project. The guide says, in part:

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority mustaddress the Product Owner.

Ways to Build Product Consensus

While "generating ideas for the product" isn't the responsibility of the Product Owner or Scrum Master, there are certainly techniques for building consensus around features and assigning priorities. Many of them can be found as free tools provided by Mountain Goat Software. They include:

• Relative Weighting
• Theme Screening
• Theme Scoring
• Project Success Sliders

However, you aren't limited to these techniques. Once the stakeholders know what they want the project to build or deliver, there are many business analysis techniques you can use to elicit good specifications, user stories, or feature definitions. Since the framework isn't prescriptive about how these details are gathered from the stakeholders, the Product Owner is free to use any of them, or to invent new ones as needed.