agile requirement gathering

[luri ron]

i have tried to adopt some technique from agile development methods such as Scrum, Extreme programming, and RUP. One thing I found that is chanllenging is that the requirement gathering time desribed in these methods is too short. in extreme programming and scrum, the requirement gathering is done in story cards or use cases within a day or two. but in realitiy, the requirement gathering takes much longer time. just want to see if anyone with agile experience has any feedback on this.

[Lasse Koskela]

"Requirement gathering" is a continuous process that often begins before a development team is set up. For example, someone gets an idea while having a shower, plays around with the idea for a couple of days, and maybe drafts some kind of a business case. This is already a form of "requirements gathering" and it continues all the way through development, deployment, and so forth. It only stops when the product is end-of-life'd.

Now, what agile methods such as XP and Scrum advocate is that you develop the product vision in the form of a backlog of requirements in parallel with software development. We do stop development for a moment in between iterations to plan our actions in the immediate future but the idea is that those iterations run back to back without a noticeable gap in between.

For example, I'm currently working on a product in two-week iterations. Our iterations start on a Thursday morning with a one-hour planning session with the product owner. We come out of that session with a rough set of user stories or requirements that we believe we can implement. The next hour, hour and a half we spend devising a game plan for the iteration and getting to the same page about how we're going to implement stuff. Then we have lunch and the following 9 days we work on the iteration content and collaborate with the product owner. Some of that collaboration is to verify that we're working on the right things right now and some of it is about grooming the product backlog so that we're in good standing when it's time to plan the next iteration. That collaboration (and what the product owner does no his own while we work on the current iteration) is basically requirement gathering.

I hope this helps.

[Ilja Preuss]

Luri,

what size are your projects? How much time do you feel you would need to gather (initial?) requirements?

[Anil Vupputuri]

Yes, Requirement gathering is a continuous process until we fulfill the requirement and each requirement might take multiple iterations in a release to be fully functional. In our case, each requirement may split into multiple iterations (each iteration spans 3 weeks) depending on complexity and we deliver the functionality incrementally.

[Lisa Crispin]

luri ron wrote:i have tried to adopt some technique from agile development methods such as Scrum, Extreme programming, and RUP. One thing I found that is chanllenging is that the requirement gathering time desribed in these methods is too short. in extreme programming and scrum, the requirement gathering is done in story cards or use cases within a day or two. but in realitiy, the requirement gathering takes much longer time. just want to see if anyone with agile experience has any feedback on this.

Luri, the reason requirements gathering can go so quickly in Scrum and XP is that you are working on a very small subset of functionality at a time. Each story is a small chunk of functionality, which still delivers business value, and can be completed in a few days. Of course, it's part of some larger feature or theme, so you're not working on it in isolation.

When my team has a big theme or project coming up, which might take us 2 - 4 two-week iterations to complete, we usually have a few meetings with the customers to learn what the theme is about, how the feature will be used, examples of desired and undesired behavior. We brainstorm about the design, we size the stories, we figure out dependencies, we choose the most basic path thru the functionality and plan accordingly. Before the first iteration, we spend an hour talking about the stories in the upcoming iteration, so we're ready to plan it during the iteration planning. By the time we're working on requirements and high level test cases for the first story, we are already quite familiar with the functionality, so it doesn't take long to write up examples, requirements and high level test cases and go over them with the customers and the developers.

Does that make sense? You have to be sure to limit the scope of each story and of the amount of work being done in each iteration so that you have adequate time to spend on each story, and complete all the testing activities for the story.
-- Lisa