Stories explain how a unit of software functionality. The intent is to make clear to both the developer and client how the the system is going to be different than it is now. A story should have:
- A short unique client or project specific id that both parties can refer back to in correspondence (i.e. #104)
- An estimate from the developer
- Approval from client
- A clear name
- Be small enough that everyone both parties can wrap their heads around it.
Starting point for understand
One of the key implications if stories is that both parties need to have a pretty good understanding of what the system does right now in order to for this process to work. If developers are writing overly detailed stories when the system is still nascent, their estimates will be mediocre at best. And if the client doesn’t understand the intricacies of their own software, they won’t be able to make informed judgements about the cost of the changes.
Ids don’t need to be globally unique
Having used quite a few software tracking tools over the years, each one definitely has it’s own warts to be sure. One that is particularly troublesome variant though though are trackers that don’t assign any ids to each ticket/story/issue (or whatever a system happens to call its unit of work). Or assigns an equally useless globally unique id.
This creates endless opportunities for miscommunication with clients. Ideally, it should be easy to write a simple email saying that issues #102, 123 and 124 are deployed to a staging server for testing. This inevitably leads to numbered bulleted lists in emails, where what #1 refers to changes from email to email.