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?

  • Product brainstorming is really more of a marketing or Project Charter issue. Within Scrum, it's not the Scrum Team's responsibility to define what the product should be.
    – Todd A. Jacobs
    Commented Sep 9, 2015 at 20:30

2 Answers 2


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

  • I think it is essential for the Sprint to have a clear understanding of the customers needs.. It's often the case that the customer got features he didn't ask for. so I'm looking for techniques to get a better insight in what the customers intention is.. Commented Sep 1, 2015 at 13:10
  • as I understand the discussion is about how to understand customer needs better, is'nt?
    – AndriuZ
    Commented Mar 2, 2016 at 13:04


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:

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.