Thanks for sharing your feedback and question Edy. Product backlog refinement is about discovering the right solution and making effective detailed product decisions. Design thinking is a much broader approach that covers product discovery elements. Hope this helps!

Since I’m new to agile & scrum, I found your sharing very helpful for me to getting started with.

I would like to know how to relate product backlog refinement steps and design thinking activities. At some point, I think they are pretty similar, especially product backlog refinement steps 1, 2, and 4, only that design thinking is more guided & structured.

Thank you and my best regard from Jakarta.

Edy Salim

Hi Lucy, Thanks of sharing your question. Product backlog refinement is the current term used by the Scrum Guide to refer to detailing, estimating, and prioritising the backlog. The traditional Scrum term is “grooming”. As both terms refer to the same set of activities, I recommend that you use the one that you are more comfortable with. Bear in mind, though, that analysing user feedback and applying the new insights may lead to larger changes in the product backlog that go beyond refinements and incremental enhancements.

Hi Andreas,

I know this sounds like a cop out but the best advice I can give you is: Attend the next retrospective, and talk to the team about the issue. There could be many causes: Team members might feel they don’t have the time to contribute; the team members might have a wrong understanding of the product owner role; the team members may lack the knowledge or skills to contribute; or the team members might be worried that hey could be held accountable for the product’s functionality.

Good luck!

I am having troubles to communicate to my three dev teams that grooming the product backlog is a shared responsibility. Their understanding is that the stories which enter the grooming session are already well prepared. Estimation is what is done in the grooming session. They demand other kick-off meeting to discuss stories in details and talk about how to solve them. Apparently, stories in the form of “As a user I want to do X so that I get value Y” is not enough specification to my dev colleagues.

Maybe you have an idea how to bring business and engineering together in order to generate good PBIs.

Thanks!
Andreas

Glad to hear that my advice was helpful.

Hi Andreas, Thanks for your comment. I recommend that you add bigger refactoring items to the product backlog, as this creates transparency and facilities planning. For instance, you want to add new functionality but still meet your main performance constraint. The team has identified the database access layer as the main refactoring area. Now add the following refactoring item to your backlog: “Refactor the database access layer so that the user story ‘event management’ can be provided and the performance constraint ‘response time’ is still met.” Sometimes it makes sense to create a “Snow Leopard”, a maintenance release before new functionality is implemented by the way. If Apple can do it, so can we 😉

Thanks a lot!
Andreas