Thanks for your comment, Christopher. I’d be interested to understand why the team does not want the product owner to attend the sprint retrospective and would suggest making it the topic of your next one. If the collaboration between the product owner and team is not effective ad if both parties don’t trust each other, then it’s virtually impossible to create a great product and everybody loses.

Hi Theron, I would suggest to explore how well running the two activities in parallel works for you. You may find that it is more beneficial to focus everyone on discovery if the discovery/validation effort is significant, for instance, when creating a major product update that addresses a new market segment.

I like to timebox the validation work, for instance, to one month. I also like to review the progress on a weekly basis based on the Vision Board/Lean Canvas/Business Model Canvas/Javlin Board or whatever tool is used to capture ideas and insights. I like to understand how many risks/assumptions have been addressed/validated and how many crucial risks and how much uncertainty is left on the board/canvas.

Does this help?

Roman, Makes sense. We’re trying to do discovery in parallel to scrum and trying to use retrospectives to improve the ongoing discovery work processes as well. Has resulted in: “they” need to get better ay X, or thinking is silos so far. Is there a way to do retrospectives across Discovery -> Delivery?

(Interested in your thoughts on the best way to inspect the work products from Discovery as well. Is there “demo” of validated experiments?)

Hi Theron, Thanks for your comment. It’s a great idea to look at discovery practices in the sprint retrospective. But remember that Scrum is essentially a solution validation tool, a model that helps teams build a great product – a product with the right features and the right UX. Problem validation – figuring out the target market, the value proposition, the business goals and model – is not supported by Scrum. As a consequence, teams should start Scrum once they have successfully performed problem validation. For major updates of existing products, teams may have to stop doing Scrum to do some research and validation and then do Scrum again to develop the update, or to do both in parallel (if that’s feasible). Discussing these options is something that could and probably should be done in the retrospective. Do you agree?

How do we make the retrospective process more inclusive of “discovery” type processes, relationships, and tools?

Sounds great. Thanks for sharing your approach!

Michael – as I just replied to Roman I’m saying that there may be times early in a team’s existence when the trust hasn’t yet been established. If it hasn’t then its important to establish rapidly.