Does your Scrum team or someone you love suffer from not knowing who benefits from your work? Do you finish items quicker than you anticipated? Do you have times when you can’t tell if an item is done? Do you ever take on too much work? Do you never talk to anyone about the item you’re working on? Do you think this article is asking too many questions?If all this seems like the set up for an ad from a legal firm, you probably watch too much daytime TV. But if you read this list of questions and answered no to all but the last one, then we need to talk. Well, at least you do. Because items likely are reaching your product backlog without any conversation about what you are doing, why you are doing it, who you are doing it for, how you will do it, or what success will look like. And that’s a recipe for disaster (although most disasters happen because no one has a recipe, but that’s another story).
Without conversation, you have a product backlog of features, functions, requirements, and fixes that are not thought out, make no sense, have no estimates for completion, or are too big to be handled in a single sprint. And that never, ever works out well. If it did, you wouldn’t be reading this, would you?
But there is a better approach to adding items to your product backlog—one that gives each item a sense of purpose, an established timeline, clear expectations, and an idea as to what success looks like. In other words, it puts the refinement in backlog refinement. It consists of three C’s, none of which stands for ‘cookie’:
Card: not as in greeting cards, but as in cards that contain the user story for the product—the who, what, and why for the work at hand. Essentially, these cards capture the essence of what you are doing so you can scope out the project size and complexity. If you cannot capture the essence of the user story on one card, use that as an opportunity to break it up into multiple stories and not as a challenge to write as small as you can to get everything in.
Conversation: once you’ve plotted the user story, the product owner and the team can use the cards to engage in dialog about how best to approach the tasks at hand based on that information, such as how each item fits within the product backlog, how to stack them based on priority, and how to break down complex tasks so they can be completed in a scrum. Hint: if anyone is using the word ‘and’ a lot in talking about the tasks they will do, that’s a good sign to break things up a bit.
Confirmation: this is where you develop the criteria to determine that you have completed the user story on each card. This typically involves a series of yes/no questions. For example, if the user story is related to strong passwords, your questions might be ‘should it have at least eight characters?, (yes!) ‘should it contain at least one uppercase letter?’ (yes!), and ‘would ‘password’ be a good password?’ (hell no!)
There is one more C that will help you in successfully tackling your product backlog: counts. In other words, count the conversations you have related to each user story. You don’t have to videotape the conversations or take notes, unless your team is eminently photogenic and quotable. Just track how many conversations you’ve had about topics such as ‘who the item is for,’ ‘what they want to do,’ ‘why the person needs it,’ ‘how to verify it is done,’ ‘how it compares with other product backlog items,’ and ‘can it be completed in a sprint.’ You can keep count however you like—on a whiteboard grid, on the actual cards—you name it. Well, except tattoos. Do not keep track using tattoos.
Keep in mind, these are real conversations you want to track, not instances where someone said ‘do this’ and someone else nodded or grunted. Achieving a mutual understanding on each product backlog item will go a long way toward enhancing not just the quality of the work you and your team are doing but also the outcomes—the reason you’re doing the work that you do.