One need not be too fussy and fastidious about words and terminology we use as long as the intent is clearly communicated and the action plan is well communicated. But sometimes usage of a wrong word leads us to think in a wrong way. For example, ‘Testing Story’ or ‘Technical Story’ or “Hardening Story” or “Design Story”. I have even come across “Training Story”, no kidding.
In reality,
there is no such thing. There is just ‘User Story’.
As
Allen Holub says, a User Story is an expectation from the software as expressed
by the end user so that the software helps the end user in his/her **DOMAIN LEVEL WORK**. If User Story does not relate
to the Domain level work of the User, then it is NOT a User Story. Naturally “Ability
to Login” is not a User Story for accounting software, because login is not
domain-level work of an accountant. Had it been a Domain Level Work of an accountant, it would have been covered in Accountancy textbooks.
Most of the people I come across use “User Story” as a code word (or a place holder) to package any kind of work. They also feel that unless they use this code word, their Agile certification will be taken back 😊.
So they try to force-fit any kind of work
using this Agile syntax ...“As a XYZ I want to do ABC”.
And in the
process, they do not hesitate to use Developer in place of XYZ.
That is, they themselves become users of
their work, just to satisfy the “Agile syntax” of a User Story.
No comments:
Post a Comment