Jake Worth

How I Make Sure I Understand a Feature Before Building

Published: March 02, 2022 2 min read

Not ready for work: “Let’s add social login to our website”.

Ready for work: “Logged-out customer sees Google login button,” with detailed acceptance criteria.

So, how do we get there?

I think the most important factor to consistent delivery is understanding the work. When you understand the work, you build better and faster. You build what the stakeholder wants. In this post, I’ll explain how I go from a vague idea to a deliverable unit of work.

It starts with a question: “What is the why?” What’s the point? How does this help the customer and the business? In the military this is called Commander’s Intent. Communicating it to each individual contributor is crucial.

Following the Agile tradition, I call deliverable units of work stories. When I write a story, I follow the Behavioral-Driven-Design, or Gherkin, syntax:




This is formulaic, but it works. Why? It forces a user-first mindset. Focusing on the user dramatically increases the chances of building the right thing. And, BDD builds acceptance criteria into the story. Driving the work into this format preemptively resolves much miscommunication.

Grooming meetings are where I write these stories. During grooming, I try to think about edge cases. What does the UI look like when the data is empty? What does it look like in an error condition? What kind of user behavior should we anticipate? What’s the mobile and tablet experience? How does it work on a slow, or absent internet connection? Try to imagine your feature resilient from every reasonable angle.

Grooming includes pointing, where we estimate the complexity of the story. This is another opportunity to clarify the work. If someone proposes an outlier estimation, let them explain their rationale to expose misunderstandings or assumptions.

If I still don’t understand the work, I’ll build a prototype. This can be as simple as a Code Sandbox or as complex as a functioning application. Build it fast and simply, as a proof of concept.

You don’t have to do all of these steps every time. If they seem to complex, imagine spending months building the wrong thing. Great developers rarely waste time on the wrong thing because they create processes where unclear work never makes it to the assembly line.

✉️ Get better at programming by learning with me. Subscribe to Jake Worth's Newsletter for bi-weekly ideas, creations, and curated resources from across the world of programming. Join me today!

Blog of Jake Worth, software engineer in Maine.

© 2022 Jake Worth.