- bite size chunk (not too big, not too insignificant) of work which can provide business value, and
- can be implemented in a few days to few weeks
- understandable by stakeholders and acceptable by developers
1.User story is an informal statement of a requirement.
Many a times, I have talked to development managers, who want to see user stories as a requirement specification document, down to the last detail. In my opinion, a user story is a value statement for the business: a simple description of requirement (one line of feature), the use of requirement for the business(2-3 lines of benefit), and what conditions must be fulfilled and if delivers (few lines of acceptance criteria).
It should not be confused for a technical requirement specification document.
In essence, a user story must not be more than 100 words.
Title: one line
Priority: one word
Estimate: one word
Feature: one line
Benefits: 2-3 lines
Acceptance criteria: few lines
There are 2 fields that state the "work" to make a user story mature: estimate and priority, which are essentially indications of development effort and delivery timeline.
2. User story is a collective responsibility, and must mature before starting work.
As a product manager, I keep collecting feedback in form of a user stories in following format
Title: one line
Feature: demand/conversation
These short stories may be difficult to interpret, and may lose context with time, and need to be enriched with background knowledge and benefits of requested feature before they move up higher up in priority list.
Product manager has to facilitate interaction between developers and stakeholders, and encourage both for their feedback on feasibility, broad estimates, benefits it can have on product and business.
Title: one line
Estimate: one word
Feature: one line
Benefits: 2-3 lines
Once, a user story is accepted at this level, it makes sense to spend time to detail the story with acceptance criteria, and a fully mature user story ready to be prioritized.
For a mature product, maturing most of the user stories is a relatively easier task because most of the demands are discovered bugs or minor features. But sometimes, as a product matures in market, users start to realize limitations of the product and are ready for next level of sophistication, and such demands usually warrant a entirely new product.
3. No user story is complete until it has been accepted for execution.
Until the time a story is accepted by the development team, it is considered a live document, and everyone should have flexibility to update it with newly discovered information, be it estimates, benefits, or acceptance criteria. Almost all the time, when acceptance criteria is decided, there will be a impact on estimates.
If the story is too complex or estimates are too big, it may be necessary to break down a user story into multiple simpler user stories.
4. A user story is as only as effective as its acceptance criteria
As clear as it is stated by any experienced product team member, it is often least worked upon too. Many a times, it takes learning from past to be able to be able to write effective acceptance criteria.
Other times, stakeholders assume some criteria to be obvious or implicit, which is a definite way to be ready for disappointment when the product comes out.
Posts
