A refinement scribble – User Pyramid vs ADKAR

Posted: July 24, 2020 in Product Backlog, Product Development, Team
Tags: , , , , ,

I have a new team. It is a fairly large team with varied experiences working in an agile fashion. We’re also still figuring how design fits into our overall value-delivery chain (as an organisation, not only as a team) and recently I found myself having to help clarify some expectations and terminology which had led to some confusion and conflict.

At this point, if you haven’t read these already, I’d recommend you read these two blog posts for some background context:

  1. Change Managing our Backlog Refinement
  2. Overlaying needs, phases and quality concerns

The conversations I had with various team members led to me creating this rough visualisation of what where you are in your Epic and backlog refinement conversations means for the necessary level of granularity of front-end design.

A caveat: I believe there could be a third axis – one for “figure out what the problem is” (Product Discovery), but due to where my team was in the delivery cycle, I left it off to reduce confusion. This scribble assumes we know what problem we need to solve.

UX vs ADKAR

So how does the above work?

The vertical (y) axis represents where your Epic is in its “quality” journey. Are we still just focusing on getting something working (Functional/Reliable)? Or are we polishing a feature that is almost ready for release or is already released (Usable/Pleasurable)?

The horizontal (x) axis represents where in the refinement process we are with the team for the piece we’re hoping to take into our next few sprints.

The colourful blocks (intersections) represent what level of visualisation the team probably needs for their refinement conversation based on x and y. So if we’re just starting on an Epic and want to get to a slice that does the basics for internal testing or Beta feedback (usable) and the team have had a conversation to understand the problem and are starting to think a bit more how to slice the next chunk into pieces of user value (Break-down), then you probably don’t need anything more granular than a wireframe to work with to have the conversation and figure out the next steps. If you’re already bringing pixel-perfect designs into a conversation at this point, there’s a lot of risk that there will be expensive re-work required. There’s also a risk you’ll miss out on a more creative approach/idea because the team will be less willing to suggest changes to something that has already had so much effort put into it. Finally, because pixel-perfect isn’t necessarily required for something usable, having a lower level of granularity (in this example, high fidelity) means it’s easier to make changes when we get feedback from users of the “usable” version of the Epic.

So far I have used this tool to help team members know what they need to prep for a backlog refinement conversation, and I plan to use it when facilitating conversations to the right-hand side of the y-axis so that team members remember that “grooming” isn’t always about ready stories.

Would you find this a useful tool? If you have used it, let me know how it went.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s