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?
Mostly. They may not actually write the actual acceptance test. They may approve something you wrote. But they approve the acceptance tests. Yes.
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?
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.
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)?
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.
that's the current flow I have in mind right now.
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.
When, by whom and to which format are the requirements compiled?
First. Define "requirements". How are the different from the story itself?
What I had in mind was that the product and QA define the requirements via acceptance tests
Not usually.
during the iteration then the developer might get stuck waiting for them.
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.
Planned vs. agile processes for software can be quickly characterized by some pairs.
- Waterfall vs. iterative/incremental
- Watts Humphrey vs. Kent Beck.
- Management driven vs. team driven.
- SEI CMM vs. Agile manifesto.
- Microsoft project vs. burn down lists.
- Interim xyz review vs. scrum stand up meeting.
- Annual release vs. daily build.
- Code inspection vs. pair programming.
- Planning schedules vs. planning game.
- Committees vs. visionaries.
In someways, this question is already answered by the Agile Manifesto, but instead of reading left to right, read right to left.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Some of the comparisons above may be a little harsh, because certainly there is a lot of feature driven development that is practices with planned, and releases may be quarterly (but probably not monthly).
The best thinkers behind planned process were influenced by problems with ad-hoc or poorly suited approaches to software such as were described in Mythical Man-Month. As early as 1968, NATO had a conference on Software Engineering to try to solve the crisis and at that point. I think they had some great innovations. Page 12 of their conference report has a remarkable drawing describing waterfall but with curves instead of boxes. It also includes material about the challenges of estimating software projects. Later, planned software process experts borrowed and stole from QA pioneers like Demming and the many Japanese experts who proved its worth in manufacturing cars and electronics.
I think the best agile thinkers were extremely familiar with planned process, and reacted against its limitations, while retaining some of its strong points. Planned process has not lost all of its relevance, and some would argue it is essential for large projects. Planned is still widely used, particularly in large organizations, but many try to hybrid with agile techniques. Perhaps System of Systems design approaches are planned, but they have a good characteristic of creating small teams which is a more practical place for agile. Planned was sensitive to the need for local tailoring, but expected it would be facilitated by meetings and committees.
Great references on this topic include Watts Humphries books, articles, and technical reports on organizational, team, and personal software process. Contrast those with Kent Beck's introductory sections from eXtreme Programming Explained.
One of my professors described the history of software development something like this:
- 1970s : Tools - a Cambrian explosion of operating systems, programming languages, and tool
evolution.
- 1980s : Process - don't blame the people, blame (and fix) the process.
- 1990s : People - empower decision making and communications and interactions among people.
Best Answer
I've seen the term "iteration planning" in two contexts. The first is in the context of the Scaled Agile Framework (such as this description of SAFe's Iteration Planning) and the other is in some descriptions of Scrum (such as this Rally / CA Technologies page or this VersionOne page). I have not yet found an instance of a "Pre-IPM" event, activity, or meeting.
Based on the description of getting more details about stories, this does sound a lot like what is called backlog refinement, or sometimes backlog grooming. The Rally page mentions "backlog grooming" while the current version of the Scrum Guide as well as SAFe mention "backlog refinement".
The Scrum Guide describes refinement as more than just getting details. It's also when estimates are given and the order of the Product Backlog is discussed. Typically, dependencies or relationships between Product Backlog Items are discussed to help with the ordering. The Scrum Guide does not call out a specific event for backlog refinement, only saying that the methods for refinement are determined by the Scrum Team and should not be more than 10% of the capacity of the Development Team.
SAFe also doesn't go into too much detail on backlog refinement when it's discussed in the context of a Team Backlog. It does recommend at least one refinement session per iteration or per week, but that it's not limited to a single-meeting timebox. This means should be holding at least one refinement meeting per iteration (or more frequently for longer iterations), but work for refinement may happen outside of this meeting.
One concern that I have with calling this activity a "Pre-IPM" meeting is that you may be focused on the next Iteration Planning or Sprint Planning session. It's OK to have a few Sprints worth of work refined, and I'd recommend that you should have this. If you exceed plan in one Sprint and achieve the Sprint goal early, having an ordered Product Backlog with well refined stories can let the team work with the Product Owner on getting a jump start on upcoming work. It also gives the team a preview into upcoming work that may inform design decisions. Just don't refine too much - you don't want to end up invalidating any kind of discussions or estimates about the work as the product evolves across Sprints.