It’s a few days/hours before the next backlog refinement. You’ve been sent the epic(s) that is the main focus of the meeting.
What do you do to best prepare yourself for the refinement that allows you to ask the best questions from a quality point of view?
I feel like this is an area that I could definitely improve on so I wanted to see how others approach this situation.
I’m looking forward to seeing your responses!
Got it! I’ll start preparing the meeting as soon as the backlog refinement is finalized and the latest updates are in place. This is never happening 
, so no preparation work, and the refinement meeting is full of surprises
We have important item in hands, epic/s that are going to be discussed. Here I’do and been doing:
You can connect with Dev as well separately to learn how do they plan to implement the change. If the session its not cleared.
I guess these are well prepared scenarios ahead of the refinement session.
Lisa Crispin @lisacrispin and Janet Gregory’s @janet_gregory Feature Chat Sheet: Conversation Starters is a good oracle.
@eamond15 Here are the things we discuss in gromming call :
1. Ambiguities in requirement
2. Risks
3. Inconsistencies in functionalities w.r.t existing feature if any
4. Inconsistencies in UI w.r.t figma and story description
5. Circumstances where features behaves differently
6. Understand The Scope to define when to stop testing
7. Understand the Context : ( what is the current implementation, why change now , what makes u change this, is it not working now, whatever the story is it better implementation, business rules, or if its new story why we want to do tell us the big picture how its going to help)
impact analysis w.r.t env, configuration, DB, other features
8. Objective of the story : With this story what is it we achieve, are we streamlining any workflow, any revenue impact, how it will make users life easy
If the stories are completely new to me (e.g., no story shaping or “pre-discussion” beforehand, and no list of tickets shared with an ask to prep), I usually won’t do any preparation in advance, and instead let the PO / BA present the current state of things. In my experience, details can be changing right up until the meeting, so preparing “too soon” can often lead to wasted effort.
In your scenario, where there the epic(s) has been sent in advance, and assuming that the ask is to prepare, I would read thoroughly through the tickets, looking for things that are missing, contradictions, potential risks, the “why” of the ticket, and so on. I would also think about dependencies in both directions, and any necessary coordination efforts. Essentially, I would do the same analysis as during the refinement, except before it, and provide some feedback which may be acted upon before the meeting.
I think whether refinement prep makes sense depends on how things are done on the project, and how the refinement is run. If the PO / BA is always going to go through the ticket in detail, and not action any feedback before the meeting, then I would say that preparation doesn’t bring any advantage. But if the idea is to react to the feedback before the meeting, then go straight into discussions (as has sometimes been the case on my past projects), then prepping in advance can really make a difference.
All that being said, if preparing for the refinement really is needed in advance, I would question why some sort of story shaping isn’t done instead. That seems more structured and efficient to me.
I must admit, I do use gut instinct for my questioning of stories in refinement sessions. My biggest focus and often the thing missed is “why are we doing this?”. Often Product Managers can chat with devs only and get into ideation, produce a story based on “what the feature is”. As testers its almost more important that we know why we need to add this feature. Whats the outcome we’re hoping for when the customer gets this feature? What are they hoping for? What business problem are we solving for them? I often find that focus, drives the remaining questioning around ambiguities etc.
However, I actually think refinement sessions are quite unhealthy and ineffective as people prep for them as if it is the only point you can talk about features making the meeting quite a long one. Imagine I’ve seen a refinement meeting booked for an hour and we’ve talked about one feature because there were so many impacts that hadn’t been considered. So I would argue that the story wasn’t in a fit state to refine. When that hour was up, people had to move onto other things and we either had to organise a follow up meeting or wait until the next refinement session.
Why not encourage the Product Manager to draw on the expertise as they’re building the stories? Why not make the engagement more organic? Then the refinement session is more a quick confirmation with all stakeholders of the epic we intend to deliver rather than a big session on each story.
Thanks for all the responses everyone.
This really stuck out for me from Gary:
I think this is what I’ve seen in the early stages of refinement meetings in my current role.
The caveat is that the project is quite new for everyone so we’re still figuring out the best way to do refinements but I think it’s important for everyone to be aware of the stories and tickets before, during and after a refinement session and that refinement doesn’t have to be the be all and end all for the stories and tickets.
Oh thats 100% a journey you and your team should have. Its all about every process/meeting being valuable and if collectively you can make the refinement sessions valuable and effective, brilliant.
From my experience, their effectiveness varies. I remember when agile was first pushed with the Agile Manifesto 
. A quote from the seminar I went to was “there is no such thing as perfect requirements document, so why bother. Getting software right is an iterative process”. So alarm bells ring with me when refinement sessions become a means to construct the “perfect stories” in a one off meeting. Some features will naturally iterate in scope and the people involved will have different thoughts at different stages from ideation to implementation.
However if these sessions hit a sweet spot that works for you and your teams, be clear why it works and hold on to those principles for every session.
I think the first and most important task i will start is by exploring the epic and checking what exactly it is and what features/modules are covered in it through different user stories. As the whole thing revolve around context, understanding the context is crucial.
And then comes the next step of refinement, as I believe that for refinement or filtering of anything, prioritization is important, and the same applies here as well.
What are P1, P2, and P3 among them?
What can we put back in the backlog, and what can we pick in the current sprint?
Those tasks that we pick? What are the challenges and risks associated with them?
Any migration required or any issue that existing users can face?
What kind of testing will be required - functional, automation, or a mix of both?
What is the deadline for testing, and what is the scope of testing?
What are the impact areas?
Who are the users being targeted with this feature and what’s the business logic behind this features?
What are things we can refer for source of truth like PRD, Figma, Lucid design, or anything else?
When I get ready for backlog refinement, I usually start by reading through the epics and stories a few days or hours ahead. I try to get a feel for the scope, check the acceptance criteria, and spot anything that might cause issues like tricky workflows or edge cases.
Then I put on my tester hat and think through the user journey. I ask myself things like, What could go wrong? Is this clear and testable? Are there gaps I need to flag?
I also think through how I’d test the story and any tricky edge cases. That way, I can ask practical questions that help make the story clearer before development kicks off.
Doing this makes me feel ready for the meeting, lets me ask useful questions, and helps the team refine stories more smoothly.