No written goals are a recipe for disaster. On the other hand, a detailed description is often not practical. User Stories are a short written form for project tasks that fits on an index card.
- Formalize what a customer wants.
- Mark roles and responsibilities.
- Document a technical solution.
- Document estimates.
- Track completion status.
- Serve as a "promise for communication".
Right size:
- smallest possible action that a user can do
- smallest piece with business value.
- Tasks: no more than two person-days.
- Title + 2-3 sentences.
- Clear benefit for user.
- No technical description.
- Write stories on A6 cards, trash them if it doesn't fit.
- Use the pattern "As a X, I want to Y, so that Z."
As a teacher, I want to write grades into a table, so I don't need to write them down manually.
- keep User Stories in backlogs, on SCRUM/Kanban boards.
- keep User Stories in electronic ticket systems (Trac, Pivotal).
- User Stories versus Tasks (in Scrum).
Lets start with an example one day a sale mng walks up to a programmer, and says hello, me and my team would need sth by which we can inform our clients about stuff that we find. would it be possible to write text messages from our mobile phone and have them appear on twitter, and FB and email and other com channels.
the programmer says: sure, why not? They make a deal and the programmer starts developing. But on his way home, the sales mng thinks, hah.. mayber sth like RSS would be fine as well. but he forgets to tell the programmer.
When they meet two weeks later, he asks: how's my program? Yeah its done, says the programmer Is there the RSS feature inside? and the prog says WHAT??? and they have a serious conflict then.
So.. how to solve that?
Obviously, the problem that the SM and PROG had was that none of them bothered writing up what they are actually programming.
This is where US come in.