I was recently confronted by a customer wanting to know if Team Foundation Server (TFS) could support Product development, not just Project development. That left me a bit confused, as TFS is a general tool, and supports pretty much any process, good or bad. She had been exposed only to agile demonstrations, and she was seeing user stories being created for a sprint, and then new user stories created for the next sprint. She was wondering if TFS supported requirements, as well. After some time, I finally had the A-ha moment.
With agile, there are rarely change requests. Each sprint is a new effort, and has its own set of user stories. If an organization wants to change the functionality provided by a user story in a completed sprint, the general process is to simply create another user story that specifies the changes desired. From her perspective, this was a failure to properly track requirements. She asked a very simple question: “Even with all these user stories, where can I look to see the current behavior of the system.” And that’s when the light went on, and I understood her original question.
Requirements are used for different things in software development. Sometimes they define the work that needs to be accomplished, and sometimes they are used to define the behavior of the system. From a work perspective, whether you call the work description a requirement, a user story, or a feature makes no difference at all, especially to a tool like TFS. It is simply a representation of what needs to be created. However, when viewed as the definition of the current system, a collection of work requests can hardly be considered definitive.
Thus, the conundrum. They wanted to use TFS, but feared that using work items to simply track requested work would result in not being able to definitively answer the question “What does my system do, right now?”
Of course, Team Foundation Server can easily handle this issue. But it does require being very clear about what you’re trying to accomplish, especially when using the Agile or Scrum process templates. Interestingly, by looking more closely at the CMMI process template, you can see shades of what the person was looking for. There are both Requirement and Change Request work item types. But even in this template, it takes careful use of the artifacts to ensure that the collection of requirements defines the system behavior. The process guidance provided by Microsoft does not support this model cleanly, as it misses a clear step. (The guidance can be found here: http://msdn.microsoft.com/en-us/library/dd997574.aspx)
In order to ensure that requirements map to current system behavior you need to do the following (or something like the following):
- Define the initial behavior using Requirement work item types.
- When completed they should be Closed, by reason of Validation Test Passed.
- Create Change Request items for any changes that are linked (with an Affects link) to the affected Requirement work item.
- Once a Change Request has been approved (moved to Active, by reason of Accepted), then the linked Requirement work item should be moved back to Active (Reintroduced in Scope), and edited to reflect the approved new behavior.
- When work is completed against the Requirement, it should be Closed (Validation Test Passed).
- If the behaviors specified by a Requirement are no longer needed, a Change Request should be submitted that requests the functionality be removed.
- Once the Change Request has been approved (moved to Active, by reason of Accepted), then the linked Requirement work item should be moved back to Active (Reintroduced in Scope), and the application modified to remove the functionality.
- When the functionality has been removed, the Requirement can either go through the Resolved (Code Complete and System Test Passed) state, or moved directly to Closed (Abandoned). Note: this is slightly unsatisfactory. My preference is to go directly to Closed (Abandoned) so that these requirements can easily be filtered out of the query that returns the current system requirements. However, this means skipping the Resolved phase that would traditionally be used by testers to validate that the functionality was removed. Another option would be to edit the process template to add a new state transition reason (from Resolved to Closed) like “Functionality Removed”.
So, is it worth it? Do you track requirements as work requests, or as behavior definitions? It depends on your needs. For this organization, requirements specified behavior and were audited for FDA compliance. Having requirements track against current system behavior was important.
I’d argue that for most firms, especially agile ones, the overhead required is likely not worth the effort. But I could be persuaded otherwise. Am I wrong?