TDD is a great tool for declaring that a piece of code should do X, Y, and Z. If you don't know what the code is supposed to do, you can't write it, and therefore can't write tests.
When I have been in situations where requirements are not defined or missing key information, I have worked with the Product Manager to correct stories before they get into a team's backlog. I would sit with the PM review the story. If the definition was fuzzy, then ask for more detail. Once the story was mostly clear, then it could be pointed and picked up by the team.
Another way to tackle this problem would be to set up a way to get questions answered by your stakeholder at a more frequent cadence.
I hope this helps.
Thanks for the question!
Steve
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey Higor,
TDD is a great tool for declaring that a piece of code should do X, Y, and Z. If you don't know what the code is supposed to do, you can't write it, and therefore can't write tests.
When I have been in situations where requirements are not defined or missing key information, I have worked with the Product Manager to correct stories before they get into a team's backlog. I would sit with the PM review the story. If the definition was fuzzy, then ask for more detail. Once the story was mostly clear, then it could be pointed and picked up by the team.
Another way to tackle this problem would be to set up a way to get questions answered by your stakeholder at a more frequent cadence.
I hope this helps.
Thanks for the question!
Steve