Agile/Scrum PM and Traditional PM-Requirements
You have to start with a member of the business/stakeholder, someone who can make decisions NOT just a member of that business unit. You must make that individual a member of the scrum team, and there are only 3 roles on that team, product owner (business/stakeholder) team (developers, qa, etc) and the Scrum
Master. The business/stakeholder will create a backlog (requirements) of a list of features (product backlog) that he wants the application to have, he must also prioritize the list of features so the team knows what the most critical things for the development of the application are. The entire team will work together (unlike waterfall) to figure out how much work they must complete in each iteration. This is when the team will figure out how much work it will take to complete each feature for the application. I will talk about estimating in future posts, once the business/stakeholder agrees on the features for the application he/she must prioritize the features for the application, most important should be delivered first.
You see that you still have to perform the standard “requirements gathering", that all frameworks, methodologies employed for application development. In the case of scrum instead of the business/stakeholder just dropping off the requirements and waiting for the project to complete he/she is on the team, attending all the meetings, prioritizing features for development, thus in scrum the business/stakeholder/business analyst truly has a stake in the success of the development of the application. Face to face daily interaction should alleviate any of the “gotcha moments” that occur during traditional application development. (Waterfall)
One of the very traditional styles of gathering requirements I believe works perfectly with the Scrum framework is a Work Breakdown Structure (WBS) diagram. The definition of a Work Breakdown Structure (WBS) is “simply a list of the tasks to be performed on your project. Each task is then broken down into smaller, more manageable units of work”. If you can create your WBS in a planning session that would be practical, you can do it during a product backlog session or have a separate session to create it. It is a tremendous tool because your structure f the application is based on reality. It takes some time to create but I think the extra time it takes will save you time on the backend. Most development teams like them because it is a great solicitor for discussions and uncovering units that the team might not have thought of while reading the requirements standalone. Below is an image example of a work breakdown structure (WBS)