Edge Cases

May 13, 2010 in Adoption, User Stories

Time and again, when I’m discussing the fundamentals and foundations of agile practices, someone will bring up an obscure edge case in an attempt to show why they can’t use agile in their organization or to solve their particular problem.  There are always situations where the straightforward use of any technique requires intelligent adaptation.  In order to adapt to the situation at hand, we first need a solid understanding of the fundamentals lest we misapply the technique and end up in the weeds.

Take for example, the use of User Stories on an agile team.  Most novice teams (new to agile) I’ve coached struggle with the shift to story-based, incremental development.  Fundamental to productive adoption of User Stories requires an understanding of how they fit into the overall life-cycle of the project as well as how to identify and author good stories.

Small stories are great because they enable fine-grained prioritization by the customer.  Small stories are great because they provide a continuous sense of accomplishment to the developers.  Small stories are great because there is less to test at one time.

Yes, but what about the edge case where you have to integrate with a nasty old legacy app with no notion of an API.  How to you break the epic integration story apart?  Simple.  Create small, testable stories that each support some up-stream business need and incrementally build towards a solution.

Yes, but what if I need a large framework build or installed?  Again, think small.  Think incremental.  Think testing.  But what if we make a mistake and have to re-do everything because we haven’t designed and planned everything up front?  Well, we rarely if ever get software right the first time regardless of how much time we spend up front.  In fact, usually when we design and plan for everything up front, we get some things right, and some things wrong. Up front thinking tends to get us locked into a solution space.  After all, we’ve invested so much time and energy in designing this baby.  So maybe some of the features won’t be needed.  And maybe some will have to be tweaked to fit what’s actually needed.

Code is never written all at once, even when there is a up-front design.  The fundamental question is, how do we know when any given piece of functionality is DONE?  Stories, assuming they contain acceptance criteria (otherwise I don’t consider them stories), give us an edge.  We can objectively measure when they are complete because we can test them.  We can take large problems and divide them into small chunks to help us manage our work and reduce risk.

So, are there edge cases where user stories won’t work?  I suppose so, but I fail to understand why.  In fact, I’m not sure I understand the question.  Are user stories a panacea for our development woes?  Of course not.  But, an understanding of decomposition, incremental development, and teams with the skill set necessary to tackle the project at hand is a recipe for success.

Advertisement