I just posted a paper on agile user stories applied to enterprise telephony on Leonid’s website (Leonid’s where I work). User stories are the primary input to the agile development process. At Leonid when we do field research with our customers, we keep notes, but it’s really the stories we compile that are the primary output. The “classic” mode for compiling stories is that an agile team sits down and works with the “customer representative” who drives most of the stories, particularly at the outset. This is agile’s solution to the difficult problem of how you describe what you want, efficiently and vividly, to a development team.
Core agile doesn’t say a lot about what you do with stories once you finish an iteration, at least the write-up’s I’m familiar with (there’s a lot of literature in the space). At Leonid, we do a fair amount of “retelling” stories. First, for a feature of any complexity, we do a basic write up we call a “functional description” and we drive those based on stories. So far, so good; if you have a distributed team like we do you probably do at least some design documentation, even though the focus of agile is communication vs. going nuts on documentation. Once the feature is done, we use the stories to validate whether our customers are using the feature/using the feature as we thought they would. If the results are not as expected we reformulate or discard the story for another go around. This is also pretty standard.
But we use stories for quite a few things after that. We use them to drive documentation. We also use them in consulting engagements around service design and process design for cloud communications services, basically anything that has an element of helping a customer figure how they want to use our product. We use them a lot during training. Training is a hard thing to do well (when I say training here I mean the kind of hands-on classroom or computer-assisted type you do if you sell to enterprises). I’ve run a couple of training departments and I always find myself wanting to do better, to do more. It’s particularly hard to keep training from being boring and arbitrary. Well, if you go to a class on public speaking one of the first things they tell you is that people remember and relate to and remember stories; hence, I think, their usefulness in training. Training around stories keeps students engaged and gives you a ready-made agenda for hand-on exercises. We also use them in support. A hard problem in support is training your people to make sure they understand a customer’s intent. Stories are a great way to explain and practice that. The results have been good so far, and we’re still looking at where we can use stories to drive activity.
How do you use stories after they’re delivered in software? Validated?
P.S.
If you’re interested in learning more about stories and agile, check out Chapter 3 of ‘Starting a Tech Business’. If that’s not enough, I’ve recommended a couple of books in the Resources section of this site under Chapter 3.
