Take a More Expansive View of What Product Backlog Refinement Can Be

There’s an opportunity I’ve seen with many Scrum teams I’ve worked with – the opportunity to take a wider, more expansive view during Product Backlog Refinement (PBR)[1].

The scenes are familiar: teams focusing on one Product Backlog Item (PBI) at a time, building up just enough knowledge about the PBI to estimate its size, estimating the PBI, then moving to the next one – all in a rather rote, mechanical way.

Sometimes this scene is accompanied by otherwise good behavior – like focusing on the top of the Product Backlog and working down, making sure the team has the most knowledge about the work that is most imminent, going after what I call “just in time understanding.”  But there’s still a certain je ne sais quoi missing related to bigger picture concerns and longer-term strategy.

I recently spoke to a security expert who was concerned about his professed “inability for Scrum to handle far-reaching, strategic, cross-cutting concerns like application threat modeling and security.”  Not coincidentally, when asked he described the Product Backlog Refinement sessions he was involved in as above – item by item, tactically focused, and little room for conversation outside of getting enough information to estimate the item.

I’ve also spoken to many an architect, UX designer, and technical writer who profess similar concerns.  The long-term view of their craft – overarching architectural principles, cohesive visual design, consistent voice in text – seems to be slipping through the cracks.

Initially, I was confused, to the point of being almost dismissive: “That’s what Product Backlog Refinement is for.”  While that’s true, it’s not very helpful for a practitioner who’s never seen or used refinement as anything other than the tactically focused process described above.

I’d like to provide some solutions and real-world examples to help you use Product Backlog Refinement to solve the sort of problems with long-term, strategic concerns described above.  Everything I’ll describe follows my mantra, “Take a more expansive view of what Product Backlog Refinement can be.”

Here are some simple things you can start doing today to help your Product Backlog Refinement sessions become more strategically focused:

• Help architects, designers, security folks, etc. integrate and feel like part of your team – start simply by making sure these folks are invited to your PBR sessions. Then, make sure there’s space for them to collaborate and contribute.
• Make sure you have access to whiteboard space (physical or virtual) during your PBR sessions, and encourage anyone and everyone to start drawing and diagramming when appropriate. For example, when someone is describing an architecture, encourage them to visualize it for all to see and to annotate it with the PBIs they think are relevant.  Screenshots or digital photographs of these drawings can be attached to the appropriate PBIs.
• At least once every PBR session, step back from the details and ask simple, powerful questions that reframe the conversation a level up from where it currently is.
  • “How does all of this relate to our application architecture?”
  • “What’s slipping through the cracks with the current focus of our conversation?”
  • “How do all the individual PBIs we’ve discussed today relate to each other? Should they relate to each other somehow?”
  • “How does this fit in to our overall visual design?”
  • “What’s making you nervous or keeping you up at night?”
  • “How does this work relate to the Product Owner’s vision?”
  • “What would our CTO and/or CIO want to know about this work? Could we describe it at a higher level using accessible vocabulary?”
• Invite others outside the team, especially customers and Subject Matter Experts (SMEs), to PBR sessions. This might force some of your PBR sessions to be less freeform and more guided by an agenda (“Let’s bring Sally in on Tuesday because we’ll be talking invoices and accounts receivable”) – so use this judiciously and make sure there’s space in other PBR sessions for freeform, just-in-time discussions.
• Be open to facilitation techniques from other disciplines – for example, role-playing with CRC cards to understand object design (https://people.cs.pitt.edu/~chang/231/5spec/CRCcard/Biddle-Roleplay.pdf), affinity diagramming from the UX community (see the excellent Universal Methods of Design, https://www.amazon.com/gp/product/B007WRCRH8), etc.
• Get outside the office / virtual meeting! I bet you weren’t considering something like hitting the streets to do live user interviews as Product Backlog Refinement.  But from a Scrum point of view, that’s exactly what it is – the team building up a shared understanding about the work they’re doing.  If Scrum and agile is supposed to bring us closer to the customer, why would you be surprised that we’d physically do that in a Scrum activity?

 

With techniques like these (and others you discover yourself), I hope your teams develop an instinctual response to the perennial “Scrum doesn’t have a way to handle [x]!!” claims – with the simple but effective, “sounds like a great topic for our next Product Backlog Refinement session – let’s figure it out then!”

[1] Product Backlog Refinement was formerly called Grooming or Product Backlog Grooming – all these terms are synonyms