Search code examples
bdd

Do all developers need to participate in behaviour driven development specification writing?


I had few hours session with other 2 people in team when writing user stories.

For me it looks like wasting of time. For example - we were writing user stories for user registration feature. It looks like those are so simple things, that this specification can be written by one person.

We did not write yet tests (or how they are called) like these yet:

Given a 5 by 5 game When I toggle the cell at (3, 2) Then the grid should look like [graphics]

So I just had first impression.

The team will will be bigger than 3 people. So if connecting all the team, its will take insane amount of time. Its because - we are thinking about one thing at a time. Now like 3 people - 3 things (e.g. stories) at a time.

And I think product owners might not be happy because paying salary while not getting huge benefit.

Prepared specification is very good thing. But I think - better would be that as little as possible people write specification for a feature. And then we do meeting to discuss this specification and edit it.

I understand that later will be much more complex features than user registration. And I believe this will take even more time to prepare specification. Still - maybe as little as possible persons could make the specification, and then other people - meets and discuss it.

Also not all developers might need to discuss a feature. I think only developer who will actually work on that feature could join with specification creators and discuss.

Can BDD be done this way? Maybe I do not understand something and thats why I think its waste of time?


Solution

  • The concept of BDD is about "3 amigos". These are a stakeholder, developer and Q&A. These positions can differ, it depends on the project and company structure.

    The stakeholder is only 1 in a discussion mostly, but Q&A team or developers could have more attendees as you described in your case. There shouldn't be a rule that there must be everyone from the team. Keep the number on the minimum to be efficient, BUT MAINLY keep it optimal to be able to properly understand and describe the problem. It depends on a complexity of the feature. From my experience, mostly the optimal number is 2 developers.