3 Tips for writing business requirements for your engineering team

Feature image courtesy of CoWomen

Want to become more technical in just 5 weeks? Find out how the Skiplevel program can help.

Tips for writing business requirements your dev team will love

Recently, a product manager in the Skiplevel community asked for tips on writing stories/requirements to help developers make better decisions around improving latency. What a great question!

The business requirements doc (BRD) and user stories are the two main ways we collaborate with dev teams to build out features/apps, so it goes a long way to get it right.

While I have quite a few tips to share, here are 3 from my personal experience as a dev working with BRDs and user stories:

Less words, more diagrams

I've worked with text-heavy BRDs and diagram-heavy BRDs, and suffice to say, the text-heavy BRDs are painful and overwhelming. To make your BRD more helpful and easily digestible to everyone on the team, use diagrams instead of text as much as possible.

For all complex if/else logic requirements, create a simple user flow diagram. For metrics and business decisions, use decision tree diagrams. As much as possible, include the UI/UX mocks from your designers. You can use text to expand, clarify, or add additional information to your diagrams, but make sure to label them all so your readers can quickly reference a diagram (i.e. Fig. 1).

Write requirements that are testable and/or observable

This means doing away with adjectives as much as possible and going for numbers, mocks, and flow diagrams. For example, if you want a page to load fast, specify an explicit load time as the requirement (i.e. 1.5 seconds). This way developers can run load tests during development and can provide you proof that they've hit your definition of "fast". This makes the requirement testable.

Here's another example: if you want the app to look "nice", provide well-made UI mocks that include the correct font, spacing, and colors. This way you have visual proof that the product looks the way it should (observable).

Requirements should be presented in phases & priorities

Developers not only need to know what to build, but also when to build it and when expected delivery is. It's ok to include all your grand ideas for the short and long term goals of your product in one BRD, but break them down into phases and priorities with clear timelines.

This means your user stories should be labeled as P0,P1,P2 , and the user stories should be categorized into their individual phases for when they should be delivered.

Positive feedback is feedback too!

We often think of feedback as “critical feedback”, but positive feedback is just as important! Team cohesive and effective teamwork ultimately comes from a place of positivity and a sense of forward/upward momentum. It’s difficult to have these when just focusing on critical feedback. You want to know what you’re doing right along with ways you can improve. So as much as possible, ask for positive feedback like “What did you like about [x] that you’d like to see me continue doing?” and “What was your favorite part about [x]?”

If you want to level up your technical skills and your ability to communicate and collaborate with engineers, enroll in the Skiplevel program. The Skiplevel program is a comprehensive, on-demand course + community that helps you become more technical without learning how to code.