DEV Community

Cover image for How best to write Requirements?

How best to write Requirements?

Greg Thomas
I write a lot of code. I've also written a book on developers becoming leaders/managers called Code Your Way Up.
・2 min read

I'm working on a pretty large-scale project that is looking to ship in the next year.

I lead the Dev and QA teams (5 developers and 2 testers) - we're doing pretty well, but the team is new, there is a big learning curve for them. We are using Agile to build the solution. Prior to this, the team had built some very small applications losing a "loose Agile" approach.

By loose I mean - sprint durations changed at a whim, there was some testing, some requirements - at the end of the day, much of the workload fell to the developers - which can't scale. They didn't really track anything.

It was more - "let's just do what we always do, and we'll go back and update DevOps later" kind of approach.

Fast forward to now, we've got the devs on board with working on tasks and stories - using story points and updating hours. QA is getting the ball rolling with test cases and suites - and just recently our devs jumped in to help run test causes during the last sprint.

Where we are struggling is with the Requirements?

The customer is sending over requirement docs (which is fine, we're not going to change the world overnight) but our business analysts/product managers are taking this information and throwing it into stories and/or having the customer add this information directly into features and stories with no analysis lens being applied or back and forth with the customer. Essentially, they are copy and pasting the "information" into the features/stories.

It ends up that we have features and user stories that as one of our developers said - has a lot of information, but not a lot of requirement and requires us to go back and sit down with the customer to rewrite them.

We've spent the last few weeks working with the team to try and figure out how best to get them to translate this information into requirements that are easily digestible, roll-up to the larger customer vision, and will let us get started.

And don't get me wrong, I'm all for developers chipping in on the requirements (we are) BUT I'm not keen for them to have to redo them and then do all the development too :)

What's worked for people in disseminating information into requirements/backlog items/stories?

What has worked well for you with customers?

How do you do this in agile without a PM/BA saying - "It's agile, the devs can redo the changes?"

Would love to hear other approaches we might not have tried.

(Thanks in advance)

Discussion (2)

recursivefaults profile image
Ryan Latta

There are a few things coming to mind from your post, but I'm going to start by creating two extremes of a spectrum:

  • Requirements are known and communicated
  • Requirements are unknown and discovered through trial

Now, it sounds like you're in some weird place where one group believes the first, but the team realizes its closer to the second. The itch to resolve this must be overwhelming.

If you got the requirements perfect with your customers and built to that, would you be willing to bet your job they'd love it?

My experience with that above statement is that they are never happy and only know what they want when they see something they don't. So this is where agility comes in. If you can get your customers aligned to working with you and your team very closely you can avoid poor scope and inevitable scope creep while managing expectations.

  1. Get everyone aligned to the vision
  2. Create high-level user-centered epics to accomplish the vision
  3. For each of those create the things that need to happen and options to do it
  4. Build a very thin version across all the epics before you iterate and improve on it

To give a set of examples around these steps. Lets talk about logging in. Upon conversation, the reason for logging in is to know who is in the product to audit and customize. Ok, so the first story might be selecting from a list a role. That customizes the application. The next iteration might be asking for an email address. The next could be standard user name and pw/social. The last may be full MFA.

While my example about login may seem ridiculous, I go through this very specifically with all my clients. Many thoughtlessly assumed you have to have a login feature without a reason why. Once we get to the why and provide options, we can cut scope thoughtfully and move on. Thats part of the power of iterative development.

Anyway, happy to help further, but thought I'd offer my little bit here.

greggomatic profile image
Greg Thomas Author

Hey Ryan - thanks for this - no your example is a great one.

The problem, I think we're encountering is getting the PM/BA/Requirements people to adopt this style. At the end of the day, every client will give you their information in whatever form they have available, but it's that middle person(s) that provide the real magic in being able to provide the translation between the two so the rest of the team can follow the story.