This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Getting your story straight - User stories in XP
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
On site customer - proxy for all the stakeholders (ed. - politics). The on site customer is used instead of documentation.
Q - What about maintenance phase, which is 80%? What about doc for that? XP - XP is weak in this area.
On site customer needs to know the system requirements, Communicates context, required outcomes. Prioritizes work based on business value. Available to answer questions
Stories
Stories should be of a size where you can build a few of them in an iteration. Stories are time boxed by definition, and should be between 1 and 5 "ideal" programming weeks.
Q - What about projects that may well span much more time than that? A - XP is not a silver bullet - not all problems can be solved via stories").
Story format is not important. Has a title, concise problem statement, sketches of screen layout, etc.). Now the group is discussing how you fit in things like refactoring (etc). Some things aren't part of the explicit customer stories, but are part of their implicit desire for a maintainable, working system. Side note on my part - I can see an RSS feed for stories being a very nice fit :)
Acronym Invest
I Independent
N Negotiable
V Valuable
E Estimable
S Small
T Testable
Unit tests are not enough, we need acceptance tests as well - "When I do tis action, I expect this result". Ideally, test suite should be automated. The tests help you collaborate with the customer and iterate towards "what they meant" as opposed to "what you did". This is easier said than done, IMHO.
So - why stories on index cards? Because you can't overdo it - can't fit much text on a card. Easy to get everyone involved.
Pitfalls
System requirements may be too large to fit in customer's head
Customer does not have time to do their end
Customer is not on site
Customer blind spots (missing tests)
Losing parts of stories
Customer team, many voices
If customer spends "too much" time with the team, may lose touch with business stakeholders
Shoring up - Multiple customer teams? Story repositories?
Exercise
We took a simple order entry (CRUD) system. Split into roles (customer, QA, developers) and develop stories. Then, passed stories along to next table to look. As it turns out, the stories we received were much more complete than the ones we sent along - we were very incomplete. basically, we did not include enough story detail, and mostly omitted acceptance tests. The results were mixed - two groups created stories with tests, two groups (like ours) created decent stories and tests (within the time constraints). Very interesting exercise, opened my eyes on this area.
Previous Topic
