Skip to main content

two agile antipatterns

Both of these have been crossing my path with increasing frequency in recent months (not at work, but in conversations with others whom one would think would know better):

1) Stories are scheduled work for features. Stories should not include:
  • testing
  • refactoring
  • documentation
  • undefined customer support
  • calling your mom
The problem with writing stories for stuff other than scheduled work on features is that you completely undermine the concept of velocity.

Velocity is the number of story points accomplished per iteration. If you assign story points to activities other than scheduled work on features, you cheat the business of accurate information about release schedules. (Although it might make you feel better to be accomplishing so many points each iteration, if you are not delivering features, you fail.)

2) Doing it "by the book".

Part of the agile culture is to have retrospectives at the end of each iteration. Each retrospective is an opportunity to change your process.

So if you're doing 2-week iterations, at the end of a year, you've had 25 or so opportunities to change your process. At the end of two years, 50 process changes.

If after all of these retrospectives, you are doing your work the same way you were at the beginning, you fail.