This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
I work in a mostly scrum process. I say 'mostly scrum' because our initial requirements were the result of a waterfall design-we have been using those use cases (or stories) while doing development. My question is, in a purely Scrum (or any kind of iterative development for that matter) where/when are requirements gathered? Are a few days in every iteration (pre-planning perhaps?) used to develop these new requirements? Is everything done in Iteration 0?
When is the most practical time to develop requirements?
there are lots of different types of iterative development, from RUP and EVO that have been around for decades to Scrum, XP that have been around for 10 or so years now and Kanban that is just becoming popular. There is no silver bullet or generic way of gathering requirements that works for all that.
I personally hate iteration 0 and think that this is an idea that should have never seen the light of day, but I recognise that in many organisations people have to go through mini-waterfall as a step to an iterative delivery cycle. Many teams I work with work on requirements through a collaborative effort between business users, analysts, testers and developers. This collaboration takes place every iteration or just before the iteration, focused on converting the scope for that particular iteration (eg user stories) into something very concrete that has enough detail for implementation (eg specifications with examples). Milestone scope is typically determined by a separate workshop, involving senior people only, but this is limited to high level scope and not requirements detail. You can see a bit more on different levels of detail in requirements, when they are needed and what are good ways to represent them in the video of my talk at NDC this year.
In Specification by Example I describe the four most common patterns - all team workshops, three amigos, ad-hoc conversations between anyone who has a stake in a story and write+review. these all have different benefits and costs associated with them, so it really depends on what you are trying to achieve and where are the bottlenecks in your team/process.
Scrum by the book (the book being Practices for scaling lean and Agile by Larman and Vodde) suggests that teams should devote 5-10% of an iteration for Product Backlog Refinement. One way I've seen this done is a day every two weeks devoted to PBR, where the entire team gets into a room, spends the first third on breaking down large backlog items, the middle third on analysing and clarifying unclear stories from the backlog and the last third on reprioritisation.