User Stories & Constraints for Requirements

I am part of a project, the goal of which is to identify high level requirements, draw conceptual architecture and finally provide cost estimate of execution(based on the requirements and the conceptual architecture) of what is perceived as another huge project. The project has been going on for just above 4 months and nearing completion in a week. When the project started we defined some rules of engagement and one of them was use of agile methodologies for execution management.

We went through few planning meetings, understanding the process, team building etc. The concept was new and appealed to everyone. Things were going good, until we stumbled upon a roadblock in the first sprint and that was - How to capture requirements? In the past we had used Use cases and "shall constructs" to define requirements. We could have gone the Use cases way but it would have taken lot of time given the size of the envisioned product and our project was "time boxed". The problem with using "shall" constructs is a single usage scenario is split into multiple statements and then you struggle with combining them together for the sake of understanding or estimation.

What we were actually looking for is -

1. A means of succinctly stating the requirements in user language; i.e. In a way so that we can identify the benefit
2. Something that could immediately bring out the business value to the user.
   
3. Something that we can base the acceptance test cases on.
   

The reason being we needed a means of prioritizing the requirements and also validating them. We wanted the ability to weigh and rank the requirements so that we can arrive a product backlog that would feed into the release planning(on a side note, we envision using agile methodologies for execution management).

This led us to explore User stories(on a side note, its a terrible name! for an artifact that is tremendously useful). Here is a definition from agile modeling that I found strikingly similar to what we needed.

A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it

There is another definition( another useful resource on XP) which treats User stories as a lead to the conversation between developer and customer.

However, we were not comfortable with the format and examples as the business value was not coming up and moreover the examples were not succinct. Finally one of my searches took me to a blog by Michael James and thus i found a reference to the best book on User Stories - User Stories Applied by Mike Cohn and also a primer on INVEST principle.

We finally used the format suggested by Mike Cohn and that is

As a <User>, I can <Requirement function statement>, so that <value derived from requirement>. Here is an example -

As a Technician, I can monitor sensor data and calibration values so that I can diagnose problems in the behavior of the engine.

Note that there are 3 broad portions -

1. The User portion identifies the role. This helps in prioritizing the requirement as the product we are developing have several actors at various levels.
2. The second part identifies the requirement. This is the high level requirement. Some care needs to be taken to balance the content of the requirement so that it can be estimated.
   
3. The third part identifies the business value derived from the requirement. So for the same actor, we can prioritize what functions are important.

Although this captures the requirement succinctly, it does not do a good job of specifying the operating conditions. The product owner had it covered already through a sub-section called "Constraints". Constraints are deterrents or conditions that impact the requirement captured in the user stories and we used the "shall" constructs for constraints. As an example a constraint for the above user story is -

The technician shall be able to view the monitored values from a distance of 10 meters.

Typically there are only a handful of them if you organize the user stories properly and are easy to remember at the time of estimation.

Where we are now - We are almost done with requirements, except for a select few, the estimation has been done and we are very satisfied with how it turned out.

Where to go from here - Certainly we can write acceptance test cases. To enhance the documentation, we can expand each user story into a full blown Use case OR we can drill down each user story into a bunch of testable and traceable requirements or both. But thats for the actual project execution to decide next year. Right now, i m looking forward to the holidays.

If you have any queries, comments, please do share. If you ever used User stories, i would be keen on what your experience has been.