Re: [agile-usability] user stories - are they mini fixed scope contracts? was...
- (responding to Robin)I've just picked out two bits of your posting...
the> One of the key issues faced by many teams is creating well> written user stories. It can be difficult to clearly describe
feature.> problem without invoking some solution in describing the> Usability changes seem to arrive in two ways: - as part of a> user story (initial spec), or as customer feedback (iterative).These both have a whiff about them of problems with the'conversation' part of "Card, Conversation, Confirmation". In thefirst case there might be an over-reliance on the 'card'. Theremight not; that's for someone closer to the context to judge.The card should be a placeholder for the conversation; oneshould not need to do much more than identify the problemso we all know what conversation needs to take place.In the second case, there seems to be no allowance for changesin usability to arise as part of the conversation. Maybe this isn'ta problem because of the connotations of the word 'changes' inthis context - perhaps usability requirements arise during theconversation that are not regarded as 'changes'. Again, it wouldtake somebody closer to the context to judge.Paul Oldfield
- PaulOldfield1@... wrote:
> The card should be a placeholder for the conversation; oneAbsolutely. One of my clients is just adopting the planning game. They
> should not need to do much more than identify the problem
> so we all know what conversation needs to take place.
had a painful experience last week where the developer worked for a few
days from some notes on a card; on Thursday they discovered that he went
in the wrong direction, and some of his work needed to be scrapped.
They are having a hard time accepting that the solution to "not enough
information on the card" is to put *less* information on the card, not
more. They'll get there, but it's a struggle.