I recently attended an interesting webinar by MKS on why User Stories are sometimes an inadequate representation of requirements. I thought it raised some excellent points, and certainly got me thinking.
Starting with a refresher on what User Stories were, the presenter Colin Doyle emphasized how they are NOT a requirements document. Instead they are a placeholder for continued conversation on that particular piece of functionality and used especially for prioritization. They are the tool through which requirements are communicated and discussed rather than delivered in the form of hefty requirements documents (see this excellent article from Mike Cohn on User Stories). As Agile prescribes, in teams where face-to-face, daily communication is possible and the Product Owner and key stakeholders are readily available, the User Story format works very well. Each story follows the INVEST criteria and are first and foremost independent of other stories, and the non-functional requirements or constraints do not dominate. With each iteration, the product develops incrementally with the gradual evolution and folding back in to the project of the inevitable changes that will arise as the product comes to life. If there is a need to review the requirements and see the “big picture”, then the User Stories in combination with Test Driven Design (TDD) or Behavior Driven Design (BDD) practices, should provide all the details you need.
Colin Doyle argued the point however that there are 3 key issues with this method, all centered around the scalability:
- Too many customers for the product resulting in conflicting requirements and a significant effort to understand customer environments and needs.
- Complex products with significant interdependencies, lots of exisiting requirments and the lack of a way to see the big picture easily.
- Large organizations where “scaling of face-to-face conversations is an N2 function (Brooks)” and may include offshore or off site teams.
Therefore he recommended the careful introduction of some traditional requirements engineering practices to help solve these issues. In particular using modeling techniques such as use cases, decision
trees or event-response tables to get a handle on the big picture. This will help the project in number of ways. Firstly the developers will understand the full scope more clearly and so guide their TDD/BDD test cases and hence their code. It will also help the Product Owner who may be unable to remain fully informed for large, sprawling products. These requirements artifacts will also form the basis for a high level dependency analysis from which relatively independent User Stories and backlog items can be derived. This should ensure that you arrive at a position with nicely traceable project, from the high-level product owner level down to the actual code. The presenter was not arguing for a bastardization of the Agile philosophy by doing this requirements analysis upfront, he stressed it should be performed in a just-in-time, iterative manner, and the requirements artifacts changed and adjusted as the product develops.
I am receptive this approach. I don’t think that the Agile community should unconditionally shun traditional requirements engineering practices as “old-school” and no longer relevant. My concern with the approach is how easy it would be to slip in to a gather requirements up-front process. The models and artifacts could become weights around the neck of the project requiring constant revision, whilst at the same time being the excuse why something was done a certain way. I believe that the Agile methodology, with it’s primary emphasis on conversation over documentation, promotes an environment of “ask before you act”, to ensure that the correct path is chosen. If there is too much documentation available, this can be viewed as the definitive answer, and reduce the amount of communication within the team and clarification with the product owner.
But that is not say I am ruling this out, and in fact I think I will try and incorporate this approach in to the next complex project I work on. I think that so long as the culture of the team remains inquisitive and conversation intensive, these models can be good aides to discussion, just like user stories.