I'm getting into scrum and TDD and I think I have some confusion which I'd like to get your feedback about. Let's assume I have a user-story in my backlog, in order for me to start developing it as part of TDD I need to have requirements, right so far?
Is it true to say that the product manager and the QA should be responsible for taking the user-story and breaking it down to acceptance tests?
I think the above is true since the acceptance tests need to be formal, so they can be used as tests, but also human readable so that the product can approve they are the requirements, right?
Is it also true that I later take these acceptance tests and use them as my requirements, i.e. they are a set of use-cases which I implement (through TDD)? I hope I'm not making too much of a mess but that's the current flow I have in mind right now.
Update
I think my initial intentions were unclear so I'll try to rephrase. I want to know more details about the scrum flow of turning a user-story into code while using TDD.
The starting point is obvious, a user surfaces a need (or the user's representative as the product) which is a short 1-2 lines description in the known format and that is added to the product backlog.
When there is a spring planning meeting user-stories are taken from the backlog and assigned to developers.
In order for a developer to write code they need requirements (especially in TDD since the requirements are what the tests are derived from).
When, by whom and to which format are the requirements compiled?
What I had in mind was that the product and QA define the requirements via acceptance tests (I'm thinking of automatic using FitNesse or the sort but that's not the core I think) which help to serve 2 purposes at the same time:
- They define "Done" properly.
- They give a developer something to derive tests from.
I wasn't sure when these were written (before the sprint they're picked then that might be a waste since additional information will arrive or the story won't be picked, during the iteration then the developer might get stuck waiting for them…)
Best Answer
Mostly. They may not actually write the actual acceptance test. They may approve something you wrote. But they approve the acceptance tests. Yes.
Irrelevant. They may be formalized as automated tests. Or they may be informal and it may be your job to create automated tests from the informal acceptance test criteria.
Also. The "requirements" are the user story. There's no real need to create yet another version of the story called "requirements." Some folks to like to elaborate on the story before they code. You can call this requirements, but "design" is a better word. "Elaboration" is the best word.
Yes. The story leads to acceptance tests. The story is required behavior (i.e., "requirements"). The story leads to tests which drive software design and development.
There isn't really a lot of "flow" to this.
Story -> acceptance tests.
Story -> elaboration ("design", "requirements") -> unit tests -> code.
Story -> User being able to do something of value.
Story -> Story points -> velocity calculation.
Note the pattern. The story largely drives everything.
First. Define "requirements". How are the different from the story itself?
Not usually.
Incorrect. The developer can (and often does) help write these. That's the point of "development": elaborate the story to a well-defined "done".
Again. When you have doubts or questions, you must actually read the Agile Manifesto. The Manifesto is quite clear: developers must talk with product owners, users, QA, and everyone else who is a stakeholder. The interaction is actually the most important thing that can happen.