Saturday, October 15, 2005
User Stories
(I originally wrote this a few weeks ago - but accidently deleted it before saving it; so here I go again. I usually don't write as good the second time - but we'll see. ;) )
We use a customer proxy. Not the actual customer, but someone who represents the user. In MCI this person is a BA (Business Analyst). Their job is to act as a liason between the customer and development - turning "customer language" into "developer languge", writting the requirements, dealing with issues, etc.
For this project the BA is acting as the XP customer proxy. This has been a hugh change for the BA, but one she is mostly enjoying. The hardest part, from my prespective, is the fact that we don't have a requirements document - and that we don't need to know everything up front. As the pink book says, "Don't worry about whether or not you have all the requirements... you don't." This is showing the fallacy in the waterfall thought of "we'll get all the requirements defined, in concrete, as a contract, then we'll go write the software to fulfill them."
It has been interesting to watch the concept of having user stories, which are a promise of later conversation, take hold.
Development is pushing this, perhaps to the exteme - no pun intended. The BA says all the time things like, "Before you guys can start on, I need to find out from the customer all the details" and we are constantly coming back with, "No, you don't. If you do, great. But if not, it won't hold us up, because we aren't to the point where that matters yet." And it even goes past that to, "Well - we'll make an assumption and code it one way, and because we are so *extreme*, *fast*, having *unit tests*, etc. - it won't be hard for us to change that if we have to." This is so foreign of a concept. She keeps shaking her head and saying things like, "I keep forgetting... I don't need to know every little detail up-front." In the past, development wouldn't start anything, until everything was known.
The other day something changed (I forget what - which in itself is kind of telling. The fact that it changed was so minor that I don't even remember what it was) - and she said, "Do I have to create a change control for that?" A change control is where something changes and a document is issued which discusses the change, how the current requirements document will be updated, the impact to development, and all the other groups (test, QA, etc.), and have to get assesments from all the groups, etc. We said, "Change control? No, just change the story. We haven't started it yet, and so if you change it before we get to it, no big deal. And even if we had already done it, the change is minor and we'd just update the code and rerun the test."
While this is very different from what the BA is used to, and hard for her to internalize at times, I believe she is loving it. She occasionally shakes her head and says things like, "This is so much easier.", "This is great that I don't have to know it all before you guys even start things", "This is awesome that I can ask for a change before the release goes out and it isn't a big deal." This is a BA that really wants what is best for her customer, and frequently gets teased that she is the "Change Control Queen" - because as a 3 month project drags on, she is always coming up with new things that she'd like to get "squeezed into the release". With XP, she has the ability to add things at any time (as long as she removes something else) - and she is totally cool with it.
Anyway - this kind of turned into more than just a User Story discussion. To get back on track - we think we are doing OK with the stories. They *may* be a little too low-level, they may be too developer-oriented. But they seem to be working for us, and I'm sure we'll learn as we go.
We use a customer proxy. Not the actual customer, but someone who represents the user. In MCI this person is a BA (Business Analyst). Their job is to act as a liason between the customer and development - turning "customer language" into "developer languge", writting the requirements, dealing with issues, etc.
For this project the BA is acting as the XP customer proxy. This has been a hugh change for the BA, but one she is mostly enjoying. The hardest part, from my prespective, is the fact that we don't have a requirements document - and that we don't need to know everything up front. As the pink book says, "Don't worry about whether or not you have all the requirements... you don't." This is showing the fallacy in the waterfall thought of "we'll get all the requirements defined, in concrete, as a contract, then we'll go write the software to fulfill them."
It has been interesting to watch the concept of having user stories, which are a promise of later conversation, take hold.
Development is pushing this, perhaps to the exteme - no pun intended. The BA says all the time things like, "Before you guys can start on
The other day something changed (I forget what - which in itself is kind of telling. The fact that it changed was so minor that I don't even remember what it was) - and she said, "Do I have to create a change control for that?" A change control is where something changes and a document is issued which discusses the change, how the current requirements document will be updated, the impact to development, and all the other groups (test, QA, etc.), and have to get assesments from all the groups, etc. We said, "Change control? No, just change the story. We haven't started it yet, and so if you change it before we get to it, no big deal. And even if we had already done it, the change is minor and we'd just update the code and rerun the test."
While this is very different from what the BA is used to, and hard for her to internalize at times, I believe she is loving it. She occasionally shakes her head and says things like, "This is so much easier.", "This is great that I don't have to know it all before you guys even start things", "This is awesome that I can ask for a change before the release goes out and it isn't a big deal." This is a BA that really wants what is best for her customer, and frequently gets teased that she is the "Change Control Queen" - because as a 3 month project drags on, she is always coming up with new things that she'd like to get "squeezed into the release". With XP, she has the ability to add things at any time (as long as she removes something else) - and she is totally cool with it.
Anyway - this kind of turned into more than just a User Story discussion. To get back on track - we think we are doing OK with the stories. They *may* be a little too low-level, they may be too developer-oriented. But they seem to be working for us, and I'm sure we'll learn as we go.
