Thursday, October 25, 2007

Agile Development and Requirements Tracking

I'm currently in the process of building a business-case for wider-adoption of Visual Studio Team System and Team Foundation Server within our company. During this process, I've come to learn a couple of things:

  1. Agile Development ROCKS - I've stated before that I believe any Business Intelligence project is going to be best served by an agile process, and since my life over the last year has been deeply rooted in business intelligence, I've been living this. Having had to stick my head up over the wall and take stock of what others are doing, I can only say that I am so happy that I'm doing what I am... :)
  2. Agile is not for everyone! - This is a well-known fact, but it bears repeating here. Many development teams have their lives dictated to them by a series of requirements and are used to functioning in that manner. They tend to want to know exactly what they're building when they start.

One of the big differences between Agile projects and more traditional methods is the way in which requirements are gathered and tracked. In an Agile project, requirements are thought of in terms of business scenarios, which can be related roughly to use-cases. While in the requirements phase of an Agile project, Product and Project Managers spend the bulk of their time developing the scenario. The process generally looks like this:

  1. Product Manager interviews potential customers to determine basic functionality. Product Manager compiles customer feedback into a series of "things" that they want to accomplish with the product.
  2. Product Manager writes a business scenario for each of the high-level "things" that the customer wants to accomplish.
  3. Project Manager examines each business scenario and gathers input from the team on how difficult it is.
  4. Project Manager takes a SWAG (if you haven't heard this term before, WikiPedia it - second bullet under initialism) as to how long each scenario will take.
  5. Product and Project Managers negotiate a rough development schedule that everyone agrees will change. (This bullet is by far the most important one in the process and is the number one cause in my opinion as to why Agile isn't for everyone!)

For this reason, the Microsoft Solutions Framework (MSF) for Agile process template that is included with Team Foundation Server does not include a "Requirement" Work Item type. Over the next few days, I'm going to be spending time adding the CMMI "Requirement" WorkItem type to the Agile template and customizing the linkage between a scenario and a requirement.

No comments: