Tom Breur
7 June 2015
A User Story is a reminder
to have a conversation with the business. As I wrote in an earlier
blog article, this is something radically different from ‘traditional’ (Waterfall)
specifications. I see two main differences:
1. Stories are short,
succinct, and Lean.
Agile is the art of maximizing the work not done, we sometimes say. We rely on
face-to-face conversations instead of written documentation.
2. Stories materialize Just-in-Time.
Minimize and defer spending any time on it, until your information analysis
will be put to use. And no sooner.
Why have we adopted these
practices? You
never get requirements 100% right, and (personal) interaction is best
suited to sort out any differences. Also, requirements have a shelf life, go
stale. I suggest that you periodically empty your backlog. What? Yes, that’s
right.
If Stories haven’t
materialized in, say, 3-6 months, you are better of purging them from the backlog than leaving them in. Get fresh
inventory. A Story that is merely “waiting” in your backlog obfuscates reliable
Velocity
measurement, as my colleague Michael Mahlberg has explained.
Yep, deleting Stories you
previously entered is painful. But also a useful reminder. Don’t prep (some
call this “grooming”)
a Story until you plan to work on it.
Stories that consist
solely of the synopsis are fine though (if that’s how you like to work). If you
inserted it ‘just’ as a reminder, the placeholder will still be there if and
when you need it…
No comments:
Post a Comment