5 Common Mistakes in User Stories

Remote control programing

User stories are not really requirements in the traditional since.
User story is a description of the problem we are trying to solve.
If you don't understand the problem you will not be able to solve the problem.

Stories as a Contract

Writing stories as detailed definitions of the change you want, this should not be a detailed definition, but should be simple and a placeholder for a conversation.
Avoid contracts, to improve collaboration
Conversation is higher bandwidth than written word.

Monster Stories

High quality work is small, fast steps
Keep them small increment in behavior of the system
Stories should be completed within a sprint at minimum but preferred to only spend a day or two.

Value means Valuable

Even the small stuff can be beneficial
Move the items forward from the user perspective with small steps
Fifty Quick Ideas to improve your User Stories
Good software takes time even if the value is small along the way.
User Stories are a tool not a religion
What the system is meant to do NOT how it does it

Dependencies between stories

Inevitable that code builds on top of other software.
Stories may get easier to write
User stories should be atomic, they can be implemented in any order.
Do good work, and focus on the user story; Don't over engineer

Use stories as a tool to focus the development team not replace requirements in a different format.

github-actions[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.