Tom Breur
1 February 2015
Some people view User
Stories as a special kind of, “Agile”, requirements. They are not!! A User Story is no more than a placeholder in a
prioritized list of “things to do.” Features we plan to build. You need
something succinct if you quickly want to go through this list. They’re great
for that. User Stories describe, in some commonly agreed shorthand, what a
dialogue between developers and the Product Owner might sound like. Mike Cohn
has written the reference title on this subject: User
Stories Applied.
It can be tempting to
“rely” on User Stories, and omit a face-to-face meeting with your colleagues.
Not a good idea. A User Story is “merely” a reminder to have a conversation
about the real user requirements. By
the time you are ready to start building this feature. As one of the Agile Manifesto principles
states: “The most efficient and
effective method of conveying information to and within a development team
is face-to-face conversation.”
The “just-in-time” aspect
is also important. Don’t waste time in requirements sessions until you are ready
to begin development. Requirements are subject to decay (and so is your memory,
for that matter). What seemed important a month ago (or longer…) may be less
desirable today. Best to find this out before you start building! And as you
are developing, it is a good idea to check back from time to time, to test
assumptions, and ask clarifying questions. Again, the Agile Manifesto principles
states: “Business people and
developers must work together daily throughout the project.”
Are you having these
conversations on a daily basis?
No comments:
Post a Comment