Tips and Tricks for a Great Refinement Session

A conversation between a manager and a product manager on their team as he prepares for refinement of a new feature.

Today we're discussing refinement.

The concept of refinement, also known as backlog refinement, is a critical part of agile development methodologies. It is a recurring meeting where the product manager or product owner and the team discuss and refine user stories to ensure they are ready for future development cycles.

I'm going to talk to you as if I was your manager and you're a newer product manager (named Jimmy) working within the E3 Framework.

Conversations about refinement between me (manager) and Jimmy (product manager on my team).

Me:

Hey Jimmy, as we’ve been discussing, you that you are the glue to getting a capability to production in the most effective, efficient manner (second most important thing) with the most value for the business and customer (first most important thing).

Great job with the formal kickoff! It was great to see our lead developer, architect, and UX members along with our business leaders in attendance.

I appreciated you reviewing the strategy related to this capability build-out and how you covered the metrics including our current state, what signals we need to know if we're successful.

Now that we are all clear on the problem we are solving and our success criteria, What steps have you taken to get ready for refinement?

Jimmy the PdM:

Thanks for the feedback and support with the kickoff. Creating the pitch deck made it very easy to tell the story in that meeting. For refinement, I'm ready... I've got a few user stories to get us off to the right start and then some that I need to get feedback from customers before we build it, but we can still refine it.

What's the first tip for having an incredible refinement?

Me:

Before we get to refinement, tell me more about your user stories.

Jimmy the PdM:

Well, I did a ton of research and I think I know the premise of what I want to build, but there are still a few big decisions we need to make about steps 4,5,6 in from the journey mapping we did. Mostly what I need to know is if we can technically handle what UX and I have been envisioning.

Me:

Before you host a refinement, may I recommend a pre-refinement with your lead DEV and UX to get the feedback you need to make a quick decision instead of bringing the whole team into a workshop atmosphere in refinement vs. a review of the work that results in extreme clarity.

Tip 1: Pre-refinement with your lead co-creators does 2 things

1) saves junior co-creators from joining calls where they don't need to engage and gives them time back and

2) gets the basic questions and direction out of the way so you can be more confident in your refinement with the overall team

…a few days later…

Jimmy the PdM:

Pre-refinement went great. I got some clarity, but we have a lot to review still. The conversation shifted to what Phase 2 of the feature will be so we can make sure it's scalable for the next few iterations. We need another 30 minutes tomorrow and then I'll be ready for refinement.

Tip 2: Sequence the user stories you refine based on priority. Discuss future phases in terms of scalability, but focus on getting understood work in the hands of your developers.

Tip 3: If you refine too far in advance, your co-creators will forget what was discussed (even with good commentary) and

1) you risk less quality work if the team doesn't want to admit they don't recall all the specifics from the conversation and

2) you will have to repeat yourself, making your time spent on backlog refinement increase.

<Day of Refinement>

Jimmy the PdM:

Thanks for meeting with me on the roadmap update. While we have a few moments, refinement is later today and wanted to discuss the game plan, quickly. The pre-refinement activity solidified our user stories. I'm hoping to cover about 10 in the hour.

Do you mind reviewing a few pointers before I get in there? I'd like to be as productive as possible.

Me:

Sure!

Here is my refinement checklist of tips

—

• Show up confident that your user stories are clear and concise. Strong beliefs held loosely. To get more confident, do more pre-work.

• Review your user stories in priority order—this helps the team know what is most important.

• While reviewing, if changes are needed to user stories based on the convo; put a comment on the JIRA ticket and keep going. This transparent organization for a follow up is key for the team to see (builds your team’s confidence in you) and also lets the flow of the meeting continue without stopping for updates you can do later.

• Encourage discussion, questions, and feedback—this will help ensure story point estimates, complexity, effort, and any risks are brought up so you have more clarity around what the level of effort will be. 

• Call out specific people's names and invite them to speak if you know someone is more introverted but generally has great ideas and approaches to share.

• Refer back to the epic and/or the strategy that this user story relates to. Remember, if it is a "global" assumption, just point them back to the epic instead of repeating it for every user story.

• Bring designs / system mappings along with you to refinement to help illustrate the point.

• Using acronyms? Make sure everyone is comfortable and understands them.

• Have a whiteboard handy or iPad with whiteboard capability.

• Be solution agnostic! 

Jimmy the PdM:

This is great! I'll create a confluence page so all the PdMs can benefit.

Me:

Remember…

You don't code (but maybe understand a little)

You don't design (but it looks easy, right?)

You don't test (this comment does not include folks in my startup... btw testing and UAT are very different)

What you do is represent the customer and ensure you guide the discussion and land on decisions that provide value for them and the business. Always relate back to how the specific details in the user story relate back to the overall end-to-end experience.

This won't always be easy, and you'll need to become great at overcoming hurdles, and overtime the rinse and repeat process of the E3 Framework will become much more familiar and you'll be consistently successful completing your day-to-day work.

Jimmy the PdM:

We have a lot of functional stories to get through. I'm glad we covered the customer and metrics in the kickoff. Now we can dive into the work.

Me:

Agreed! As we get closer to launch, let's make sure to remind everyone of our strategy and what signals we are looking for. This will get everyone invested in the outcome.

….post-refinement…

Me:

Hey Jimmy, thanks for meeting me for our 1:1…what's top of mind?

Jimmy the PdM:

Hey, refinement went great. We were able to get through the 10 stories but had to circle back to one particular portion of the feature.

So we're thinking that this feature can be built a lot like the last one; makes sense to me.

I mentioned we should use the same architecture we did with these databases and systems.

Me: 🫢

Did you recommend this or prescribe it?

Jimmy the PdM:

Well, I did mention in the user stories that this is the way it will be done. I assumed we would do it that way because we did it like that last time. By the time we circled back, the team agreed on the approach.

Me:

Glad you got to an agreement, but I'd like to have a coaching moment.

Recognize that you may have boxed in your co-creators to a way to solve. Not every developer is great at pushing back, even when there may be a better way they would solve it.

Tip 4: When product starts to prescribe how a capability should be developed, designed, or tested - we are now telling our co-creators how to do their job. It's appropriate to ask questions, provide suggestions, and point to solutions that could work, but make sure it's part of a discussion and not written as part of the requirements.

Jimmy the PdM:

But... there is context from previous releases about how we coded, designed, and tested.

Me:

I understand, glad you see that trend. Let's talk about how to give that message. What's another way to bring it up?

Jimmy the PdM:

Well my intent was never to box them in. Any suggestions?

Me:

Framing it like the following is an option..

"I believe that we utilized specific tools for a previous release that was similar. You are the expert but from my vantage point; seems like the customer has had similar experiences that we built and just curious if those tools make sense for this build-out?

Just a thought!

Notice how that verbiage shows intent to help, but no attachment to the outcome. Just another input into your co-creator’s overall decisioning, but not the decision.

Jimmy the PdM:

That makes sense. I'll get better for the next go-around. Thanks for the coaching. Time to go analyze data for our last release!

Me:

Sounds great, let me know how I can help. Talk soon!

By regularly conducting refinement sessions, the team can stay aligned on the requirements, reduce misunderstanding or miscommunication, and better plan for the work ahead. Remember, the key goal is to ensure each user story is clearly understood. Also, it’s important to recognize that it's best to prioritize task completion over self-reliance when it comes to refinement. Stay humble, be open to learning, and feedback is always a gift!

Jimmy is well on his way of repeated success when refining with his team, creating momentum, confidence, and a bought in team. All of that translates into more effective and efficient co-creators which leads to capabilities being available sooner, with higher quality, and the intended scope.

Best of luck in your next refinement, I hope this helps both tactically and recognizing how important refinement can be to a strong product.

Until next week.

Jason