A pet peeve of mine is when people say "user story" as a generic term for any discrete chunk of work the team needs to accomplish.
And I don't mean this in a procedural sense, like you forgot to write the requirements in the classic "story" format like:
As a [type of user], I want [some functionality], so that [some benefit].
There's something very revealing about how teams write their requirements. Some teams have a product backlog filled with "user stories" written like this:
When you click on the "Edit Account" button, show a modal dialog with the title "Account Editor".
The modal contains:
- A dark green button in the lower right corner with the label "Save Account"
- Next to the "Save Account" button there should be a light green button "Close"
- A field with the label "Account Number" is pre-filled with the account number
…
At the surface level, you can see that obviously this work item is not written in the typical user story format. So you could say, hey, we should write the requirements more like this:
As an administrator, I want to edit an account, so that the account is up to date when information changes.
That's better…maybe…but the real issue is not the format in which the requirement was written. The way a requirement was written can often indicate who we're hoping to please when the requirement is met.
When we approach software development as a series of user stories, we're seeking to please a user with each chunk of work that we deliver.
All too often software development proceeds more like a series of manager stories, in which we are pleasing someone in the team's management chain with each chunk of work delivered.
Some software organizations are set up like a feature factory, in which a management function beyond the development team decides ahead of time which things to build and the specifications of their design, and then parcels these chunks out to the development team on a sprint cadence.
