Product Backlog Refinement: What NOT to do
Вставка
- Опубліковано 29 чер 2024
- Building a shared understanding with the Scrum Team is vital to produce meaningful products. Yet, it's easy for Product Owners to fall into multiple traps and have meaningless Product Backlog Refinements: What should you NOT do during the refinement sessions?
- Don't plan solutions
- Don't focus on the estimates
- Don't pressure developers to discuss what they don't know
- Don't fall into endless technical discussions
- Don't bring irrelevant Product Backlog Items
To know more about it, I have the following article for you: / what-not-to-do-during-...
Subscribe for more content: ua-cam.com/users/DavidPereira8...
Take one of my crash courses to overcome your challenges as a Product Professional
- Becoming an Outstanding Product Owner: 10 years of experience summarized in 4 hours of insights. www.udemy.com/course/becoming...
- How to Become a Strong Product Owner: Learn how to avoid the traps ahead of you as a Product Owner. www.udemy.com/course/how-to-b...
- How to Master User Stories: Learn how to use User Stories to engage teams and uncover meaningful solutions. www.udemy.com/course/how-to-m...
Follow me on:
- LinkedIn: / davidavpereira
- Twitter: / davidavpereira
- Medium: / davidavpereira
You can read this content on Medium: / why-are-most-backlog-r...
Product Management. Product Manager, Product Owner, Agile, Scrum, How to improve as Product Manager
#productmanager #productmanagement #startup #careerdevelopment - Наука та технологія
4 months into a PM role. I am still 'taking the horse by the reins', and this video seems useful. Thanks!
Happy to know that. You may enjoy the content from my website too, d-pereira.com
Absolutely loved the video! First time laughing in such an informative video, honestly, kudos to you, good man! I've got an interview revolving around a Product Backlog Refinement session, and this video alone cleared up a lot of info. Thank you for the knowledge and congratulations on this new sub :D
David, really loved how you explained refinement. Thank you!
Great video, thanks for this David.
Great and clear, much thanks
Thanks so much for such an explicit feedback on this topic sir.
Welcome Legeh!
Thank you so much!!
I learned many things and gained insights from your experience. Thanks for sharing David !
Welcome! I am glad you enjoyed it.
Thanks for this great video ;)
good content! simple and efective.
excellent points
David, outstanding video, thank you for the excellent content and entertaining and supporting presentation! I have seen all too frequently that teams can mistake their overall mission as the problem for which they are attempting to define a solution. Rather, to your point, I prefer to see teams understand the customer needs, understand their pain points, and define a set of problem statements which can be brought to the team for them to find a solution. The other thing I see lacking from many teams are a solid set of requirements which would be the output of a solution session, and aimed at satisfying the solution.
I would love to hear more from you on your perspectives of product roadmaps, defining user journeys, and how you have performed usability testing.
Thanks Jim.
I will record videos related to what you mentioned. It's on the pipeline already.
Excelente vídeo cara, parabéns
Thank you David for your video! Please, I would like to understand the part where you say we must show the problem and not the solution in the refinement meeting. In our product team, we usually use the Refinement Meeting to explain to the team what needs to be built (previously we had a meeting between the Product Manager, Product Designer, and the Tech Lead to find out the best solution to the problem). But, what would it look like to have a refinement meeting with user problems and needs (opportunities) and how would be possible to put product backlog items in the sprint if we are just talking about problems in the refinement? There won't be time to better define the solution if we do so. Please, help me understand that.
Buenísimo el video, gracias 🤲🏻
Thanks Rodrigo
David, great video. I am a QA and participated of refiniment meeting. Thank you very much!
Thanks Ivan!
What did you like about the video? Curious to know it.
@@DavidPereira88, I liked principal of your suggestion of not to refinement the stories that will be not in the 2 or 3 next sprints. Because the team won't remember of the requirements after a long time.
@@ivanrodrigues4764 Thanks Ivan! I really like doing this, it avoids distractions.
this video needs to be in the front page of jira hahah
What is the name of the song!?
interesting
“Developers don’t want to implement the (a?) solution, they want to solve problems” ? Then what is their job? I could say “UX designers don’t want to do research prototyping or user testing, just fancy UI ideas” It is a developer’s job to help assist in solving users problems as part of a Team. His skillset is to actually build a bug free, stable and scalable software solution. And it certainly helps having domain knowledge and empathy for actual users of the software to make good decisions . But to think that developers just by themselves can solve problems that come from a different domain (business, UX) is just … sorry to be blunt: overestimating their Skillset.
Great UX people don't merely research or prototype, they understand what matters for end users.
Excellent developers don't merely implement solutions; they solve real problems with meaningful solutions.
It's a matters of perspective :)
@@DavidPereira88 yes, but developers solve problems within their domain: they are engineers and therefore solve technical problems with technical “solutions”. Maybe it’s a wording thing, but (me a UX Designer) had often arguments with developers in scrum settings ignoring my research and prototypes even though verified and refined after user testing. The often suggested “simpler” solutions. “Simpler” for whom? Most of the times for them. Also simple is not right, but a shortcut, causing huge technical dept, design inconsistencies and sub par UX. Many people ignore that scrum was made for in-house development of tools, not for huge and complex customer facing products.
@@karlgustav9960 I agree with you, maybe it's a word thing.
Question: do you invite developers to user interviews?
I think it's about building together and finding a meaningful solution. I don't believe in handing prototypes to developers will work well because it's like a waterfall, they receive the solution to implement and execute it. This approach does not encourage anyone to commit to the solution. Yet, I don't welcome shortcuts or options without evidences. That's why I like having all disciplines from the beginning of everything. Product Management, User Research and Software Engineering.
It's not about finding shortcuts, it's about creating value and commitment.
@@DavidPereira88 we do. They claim they don’t have time(TM) because they are busy meeting goals… in the end it is A case of Conway’s Law at scale. A Corporation is constrained to create products that are constrained by all communication processes inside the corporation. It largely depends who controls the narratives and the communication. If a Designer is at the top, you will get designed products. If a Technocrat is at the top you won’t. If you have elitists designers at work you will get elitist products. If (mostly liberitarian thinking) engineers in charge you will get stuff like JIRA, worst of all systems but the best we have :-)
@@karlgustav9960 I feel your pain.
I believe the more processes organizations have, the more opportunities they miss.
If they want error prevention, processes are amazing. However, if they want innovation, processes you block that.
I stand by my point, great teams will function as a single unit. They have a goal and together figure out how to make it happen. Silos are not part of high-performing teams.
Organizations have a choice to make, and from my experience, generally they go for error prevention. Result is clear, a lot of disappointment and poor outcome.