How I Make Sure I Understand a Feature Before Building
I think the most important factor in consistent delivery is understanding the work. When you understand the work, you build what the stakeholder wants, better and faster.
Here’s an idea that’s not ready for programming work: “Let’s add social login to our website.” Same idea, ready for work: “A logged-out customer sees the Google login button,” with clear acceptance criteria about what that means.
In this post, I’ll explain how I go from such a vague idea to a deliverable unit of work.
What’s the ‘Why’?
It starts with a question: “What is the why?” What’s the point? How does this help the customer and the business? Communicating the why to each contributor is crucial. When everyone understands it, they can help work toward success even when they are lacking precise instructions.
Storycarding and Pointing
Following the Agile tradition, I call deliverable units of work stories. When I write a story, I follow the BDD (Behavioral Driven Design) syntax:
This is formulaic, but it works. Why? It forces a user-centered mindset. Focusing on the user dramatically increases the chances of building the right thing. And, BDD builds acceptance criteria right into the story from the start. Driving the work into this format preemptively resolves much miscommunication.
Storycarding is when I write these stories. During storycarding, I think about edge cases. What does the UI look like when the data is empty? What does it look like in an error state? What kind of user behavior should we anticipate? What’s the mobile experience? How does it work on a slow internet connection? Demand resiliency in every reasonable scenario.
Next, I point the story to estimate its complexity. Try to get more people involved and reduce anchoring via voting. If someone proposes an outlier estimation, let them explain their rationale to teach the group what they’re missing or expose misunderstandings or assumptions.
If I still don’t understand the work, I’ll build a prototype. This can be as simple as a drawing or Code Sandbox or as complex as a functioning application. Build it fast and simply.
Wrapping Up
You don’t have to do all of these steps every time. If they seem too time-consuming, imagine spending months building the wrong thing. Great developers rarely build the wrong thing because they create processes where unclear work consistently gets clarified.