Hi Fiammetta,

Thank you for your feedback and question. I am not an agile scaling or LESS expert, but I hope that you’ll find the following articles helpful to decide how to best integrate product discovery into LESS:

• A Brief Guide to Product Discovery
• Six Types of “Product” Owners

Regarding stakeholders dictating features, please take a look at:

• 5 Tips for Saying No to Stakeholders
• Boost Your Product Leadership Power

Hope this helps!

Hi Pim,

Thank you for sharing your feedback and question. Some development teams do need detailed requirements, as I mention in the article. The key point is IMO to develop and empower the team rather than believing that the product owner should own the solution and therefore determine the detailed requirements. If in doubt, use a sprint retrospective to reflect on your product backlog grooming/refinement practices. Ask the dev team members how happy they are with their involvement and the quality of the requirements and listen to their ideas and concerns. Then decide together how to move forward and enable the team to take on more ownership.

As you probably know, sprints should be protected from changes. This allows the development team to focus on meeting the sprint goal, and it increases the chances that the goal is met. You should therefore reduce the need to make adjustments to the stories the team is working on in a sprint. Based on what you’ve told me, you may want to look at how you validate new and changed functionality and consider using a different method, for example, demo or usability test instead of release. This might allow you to collect feedback more quickly and reduce the need to make adjustments during the sprint.

Hope this helps!

I tend to see a tendency from development teams requiring this very badly. Asking a PO to make a definitive, final, extremely detailed list of ‘acceptance criterions’ before they are willing to pick up the work. Now, this could be a chicken and egg question; a non-empowered team might ask this more often. On the other hand, I typically value changing details in requirements during a sprint for a specific story, because looking at the first iteration of an idea leads to learning and consequently improved ideas. This comes with a risk of not being able to complete other work, which a PO has to make the trade off for.
Would you agree, or do you have other thoughts?

Thank you for your feedback Srikanth. You are right: Teams benefit from a purpose, an overall inspirational goal. That’s why I’ve linked to my article “Leading through Shared Goals“, which introduces a set of cascading goals with the vision at the top. I also mention product discovery and recommend including development team members in the in the discovery work, see the section called “Let the Team Own the Solution”. But I find it helpful to distinguish between product discovery and backlog refinement. The former refers to the activities required to determine if and why a product should be developed; the latter describes the work required to make detailed product decisions, update the product backlog, and get the backlog ready for sprint planning. Hope this helps!