“A story is a placeholder for a conversation.”
This is one of my favorite agile adages. We favor light documentation, but the only reason that works is because of our focus on collaboration. We aren’t expected to document every possible detail about a feature (and then have to read and update mounds of our own documentation) because we plan on working it out in real time: asking questions, suggesting solutions, and setting up a fast feedback loop.
But if a story is a placeholder for a conversation, when does that conversation happen? Who has it? What do they talk about? Here are five moments engineering and product should be checking in with each other to make our stories real conversation pieces.
Before Estimating
Most agile teams have some sort of group estimation sessions, such as “planning poker” or Iteration Planning Meetings. This is often the first time the engineers find out about a feature that’s coming through the pipeline. Valuable conversations can come out of this about scope, complexity, spikes needed, and possible alternatives to the work that is planned. These discussions, while useful, can derail an estimation meeting and send product back to the proverbial drawing board instead of ending the session with a story that’s ready to move forward.
That’s why it can be productive to have an engineer or two give a quick smell check to your stories before the meeting starts. Ask questions such as:
- Is this story the right size? Would it be beneficial to do a smaller slice, or to combine it with another story?
- Does this approach make sense, or is there an easier way to accomplish the goal that we should consider?
- Do you know everything you need to know to estimate this? Not to start on it, necessarily, but at least to get through the planning meeting feeling confident? Do you need to spike on it first?
This doesn’t have to be a formal meeting. Just see if somebody’s available to come do a quick “shoulder check” and provide you some fast feedback. This will make your planning meetings much more productive. There may still be questions and concerns that arise during your full planning meeting, but this is where you can knock out some of the “low-hanging fruit.”
When Picking Up a Story
When engineers are finished with a story and ready to move on to the next one, they will typically pick up whatever is at the top of the backlog and get to work. But this can be a good time for a conversation, as well. We can see if anything’s changed since the story was last updated and make sure our understanding is aligned. You might have discussions such as:
- Is this still the top priority? Is this story the thing we should be working on right now, or has anything changed?
- Do we have the same understanding of scope? Can we be explicit about what is included in this story and what’s saved for later?
- Are there any discrepancies between the story text and the mockup? Which is the source of truth?
- What’s the context behind this? Why is it important to do now? Is it blocking a downstream feature, or is an important stakeholder or client impatient to get it?
Again, this can just be an informal, spur-of-the-moment conversation. If the Product Manager or Designer isn’t available when the story is getting started, that’s fine! But if there is someone on the product side for engineering to talk to, this is a good technique for making sure the story is started off on the right foot.
When You Have Something To Show
Agile development loves fast feedback loops. That’s one reason we work on small user stories. But there’s no reason to wait for the story to be complete before getting feedback on it. When engineering has something somewhat functional (maybe the UI is done but the database isn’t hooked up, maybe you’ve handled the happy path but not the edge cases), a “drive-by” demo for product can be productive. This can be initiated by engineering (“Hey product, wanna see what we’ve got going?”) or product (“Hey dev, what are you working on?”). In this case you might be having conversations like:
- Are we on the right track? Is this what was expected?
- Does anything look weird?
- Are there any changes we want to make?
- If so, should those be done now or should we create a separate story for them?
Note that “something to show” doesn’t always have to mean UI. We could do a back-end only test where we input parameters and make sure the output is what we expected. The point here is to sanity check the work so far and make sure we’re on track.
Before You Submit a Story For Acceptance
Clicking “Done” on a story can feel so satisfying! All that hard work completed— let’s stand up, stretch, and knock out a couple rounds of Mario Kart. But not so fast: before you send a story for acceptance is a perfect moment for another “drive-by” demo. As a Product Manager, I can spot most issues with a minute of tinkering with the app in your local environment. Discussion points at this point sound like:
- Is this right? Are we happy with it?
- Are there any surprises?
- Why was something done this way rather than that way?
- How does the app respond if I do xyz? Are we OK with that behavior?
Why not just submit the story and let me test on my own machine? Because we can make the feedback loop even faster this way. If I can find issues and ask questions before you deploy to a test environment, we’ve saved ourselves that much downtime.
When “Rejecting” a Story
If you’re conducting user acceptance testing and the story is not what you expected, it’s OK to send it back for rework. Iterating on features is a focus of agile development, whether from release to release or before accepting. We know this intellectually, but it can still feel harsh when a Product Manager “rejects” a story. That’s one reason it’s good to talk in person before clicking that red button. Some questions you might ask before sending a story back are:
- How is this different than expected?
- Are the acceptance criteria not met outright, or were there mismatched assumptions about implementation?
- Are the desired changes within scope, or should we put them in another story?
- Is it worth releasing this as-is and iterating later, or should we fix it now?
Getting on the same page about the need for changes, how they would affect scope, and whether or not we can release without them is a good thing to do instead of making a unilateral decision to send it back. This can clear up confusion and prevent injured feelings from the “rejection.”
A story is only a placeholder for a conversation when those conversations actually happen. There are many times when engineering and product can be communicating directly about a story, and of course the frequency of these conversations depends on the availability of the product team. That means it’s the responsibility of the product team to try and make themselves available for these casual conversations, and of the engineers to keep them in the loop with questions, check-ins, and demos. If we all make a point to communicate throughout the story lifecycle, we can tighten feedback loops, improve collaboration, and get better features— and better products.
