Several teams at a recent coaching client have been using some form of numbering scheme for their User Stories. There isn't a global standard, but the scheme is consistent within each team. In all of the cases, the teams are not using any sort of title for the stories, just the Story Number and the Description.
An interesting conversation occurred last week when discussing the tasks for a story. It went something like this (names changed to protect the guilty):
But that isn't the issue here. The issue is simple communication. Obviously Bob remembered what Story 12a was, but others on the team did not. What if Story 12a had a meaningful title instead? What if that title conveyed just enough information to bring all the team members back to the same page?
A User Story has never been intended to be a comprehensive document of something that you need to do in a system. Alistair Cockburn said it best when he described a Story as "a promissory note to have a conversation", which highlights the critical aspect of stories - the conversation!
The intention of the title and text of a story is to provide enough context for everyone to know what they need to talk about. Throw in the acceptance criteria, and you have a shared understanding among all team members about what a story is intended to accomplish.
The further benefit to using titles is that it also provides context to people outside of the team. Anyone could walk into the team room and understand what "Search for Book by ISBN" means, as opposed to "Story 12a".
A numbering scheme may be fine for providing some indication of relationship between Stories, but it's sadly lacking in communication value. In the end, this whole Agile Software Development thing is about maximizing communication. So, let's do that with the User Stories as well.
More information on User Stories (including examples) is available on the Westboro Systems web site.
An interesting conversation occurred last week when discussing the tasks for a story. It went something like this (names changed to protect the guilty):
Bob: We already did something like this on Story 12a a few sprints back, didn't we?The team finished Story 12a several sprints ago, and all information about it had been archived and wasn't visible on the team's wall.
Bill: I think so.
Brad: Uh, I don't even remember what Story 12a was.
But that isn't the issue here. The issue is simple communication. Obviously Bob remembered what Story 12a was, but others on the team did not. What if Story 12a had a meaningful title instead? What if that title conveyed just enough information to bring all the team members back to the same page?
A User Story has never been intended to be a comprehensive document of something that you need to do in a system. Alistair Cockburn said it best when he described a Story as "a promissory note to have a conversation", which highlights the critical aspect of stories - the conversation!
The intention of the title and text of a story is to provide enough context for everyone to know what they need to talk about. Throw in the acceptance criteria, and you have a shared understanding among all team members about what a story is intended to accomplish.
The further benefit to using titles is that it also provides context to people outside of the team. Anyone could walk into the team room and understand what "Search for Book by ISBN" means, as opposed to "Story 12a".
A numbering scheme may be fine for providing some indication of relationship between Stories, but it's sadly lacking in communication value. In the end, this whole Agile Software Development thing is about maximizing communication. So, let's do that with the User Stories as well.
More information on User Stories (including examples) is available on the Westboro Systems web site.
Comments