Constraints as User Stories

A few months ago I wrote a little about constraints as an alternative to user stories. Constraints are what many of you know as non-functional requirements. Today I read an interesting post by Mike Cohn where he argues that you should write your constraints in the form of user stories. Writing your constraints as user stories is a great suggestion. It reminds me of when I was writing requirements at Ericsson a few years ago. There each requirement had to end with "because ..." which forced the author of the requirement to actually explain the purpose of the requirement. Much like what user stories tend to do.

Mr Cohn also writes a little about when these user stories should be added to the project (especially in the comments and we're promised a future blog post on that topic). From one point of view I think he is correct. Once you add any user story you have committed to deliver it. It has nothing to do with if it is a constraint or a new button doing something nifty the user wants. In the same way you cannot forget about performance once you start taking it into consideration you cannot remove that button once it is added. The difference lies in that constraints (regardless of if they are written as user stories or not) generally takes more time to implement each iteration while a typical user story costs almost nothing once it is completed. So as soon as you start taking more and more constraints into consideration your velocity might drop. But don't see that as a bad thing. It's OK. A drastic velocity drop is probably an alarm signal that something is wrong. Probably you designed your software without taking the constraints into consideration. That is not different from having a number of completely different user stories added to the backlog. The only difference is that since the constraints probably was known from the start you failed to take it into account and probably decided to implement it too late.

And that's where I think you must be careful. If constraints are treated as constraints it is obvious that you have to think about them all the time. I also think it is easier to get closure for the team since user stories added in order to comply to the constraints can be estimated and completed much like any other user story. I'm thinking about user stories created to add automatic performance reports for example. I still think it is a great idea to write your constraints as user stories. But since they're written as user stories the team might treat them as a user story and gets frustrated when they cannot get closure since the user story will just go on and on for every iteration. That's why you have to be careful. In some teams this is not a problem and in other teams it might be. But if you make sure the team understands that any story, once it is committed by the team, will affect all their future work. Some user stories almost nothing while others a lot. If the team truly understands this I think you have nothing to loose and everything to gain by following Mr Cohn advice and write constraints as user stories.

Comments

• Anonymous
  July 14, 2011
  If the constraint can be expressed in terms of an automated regression test, the implementation of the constraint user story will be the development of the test(s). These tests will be run in future sprints as you build other parts of the system to validate the constraint is still being met.