4 ms·
You can't share context indefinitely, so at some point you have to commit to a solution. E.g. "As a user, I want to be able to import the Excel reports that I
by bloomca 8y ago
You can't share context indefinitely, so at some point you have to commit to a solution.
E.g. "As a user, I want to be able to import the Excel reports that I get from company $XY, so that I don't have to manually enter the data, and save a lot of time that way" can transform into "As a user, I want data from $XY company in my system with minimal effort" during grooming or planning, but rarely during development (it is also possible, but it will break all your sprint commitments, and possibly other teams' commitments as well).
Now, regarding the broader context. It depends on the project – the larger it is, the harder it is to share it. In a small project it is very simple to describe in user story why is it needed, what is the end goal, and link to some epic. In the large projects, however, it is much more tricky, and while their example is a little bit too much, but sometimes it will literally hurt the project to share too much (not from security perspective, just from the amount of information). Sometimes there is too much info, and only PM/PO/BA know enough to judge, and sometimes such story is too big, and you end up with it being an epic, and "Implement a button" is a user story.
JIRA might work, and it works pretty well for many companies. From my experience, it is the best for middle sized companies – too much overhead for small companies, not detailed enough for too big companies.