nus-pe-script
commented
1 week ago Team's Response
Thank you for raising this concern. However, we believe documenting user stories for all roles (person, donor, and partner) is NotInScope for the current iteration for the following reasons:
Focus on Core Features
The current iteration prioritizes developing and refining key features that address high-impact use cases, such as grouping, sorting, searching, and supporting multiple roles. Writing separate user stories for each role would not contribute to the development of these functionalities, as the actions (e.g., adding, editing, deleting contacts) are consistent across all roles. Including these details at this stage would divert focus from higher-priority tasks.
Redundancy and Unnecessary Length
The user stories for other roles are inherently similar in nature to those already documented for the volunteer role, with volunteer serving as a representative example of the possible roles. Adding repetitive user stories for every role would make the documentation unnecessarily lengthy and harder to navigate without providing additional value. The current documentation effectively covers the shared functionality through representative examples.
Core Objective Alignment
The goal of the user stories in this iteration is to clarify core functionalities for developers, not to exhaustively detail every potential use case. The primary focus is on role management and engagement tracking as a whole, rather than providing granular descriptions for each specific role. This approach keeps the documentation concise and aligned with the system’s objectives.
Effort vs. Value Tradeoff
Including user stories for every role would require additional time and effort without delivering significant value to the development process. The functionality for all roles is already implied by the current stories and does not introduce new complexities or requirements. In the actual code implementation, actions for different roles are handled as a unified process, meaning there is no need to write separate methods for adding or deleting each individual role. This shared handling further reinforces that documenting each role separately would be redundant and unnecessary, and does not add value for developers reading the DG.
Conclusion
Adding user stories for the remaining roles is a valid improvement to consider for future iterations if needed. However, it is NotInScope for the current iteration, as it does not align with the priorities or objectives of the ongoing work and would unnecessarily complicate the documentation.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: (similar response as for "delete person missing from user stories" but my response to that one is slightly clearer)
From my understanding, an issue can be classified as not in scope if significant effort is required to rectify it and the effort can be channeled to other areas instead. I believe this issue is in scope.
Based on your response, if your objective was actually to provide a general representative example, you literally already have a role that caters to this: "Person" (which i focused on in my bug report -- left it outside brackets because person is what's most basic/general). All you have to do is replace ONE WORD in like 3 or so user stories...
Your user stories should capture the desires of users, in order for you to decide on what to implement. By only specifying that users want to add/delete/edit "Volunteers" (not even a general role like "Persons"), it leaves the remaining requirements uncertain. Perhaps, the lack of a desire to add donors/partners might signify that your app provides NGOs with a fixed list of suggested donors or partners they can contact? Who knows?? Not the developers trying to read your user stories to figure out the requirements.
Therefore, like you yourselves admit, using a general representative in the use cases is useful. Just make sure your general representative is general and can encompass all roles and so is not a niche role (especially when you ALREADY have a general role -- "Person"). Just changing it to "Persons" makes it so much more clear and actually conveys what you want to mean.
(from your UG)
As the effort is as simple as replacing "Volunteers" with "Persons" in order to actually have a general representation, I cannot comprehend where else you could put this tiny amount of effort into, to justify leaving this out of your current version. Especially since you specifically created the "Person" role to be general so it's just sloppy and incorrect to create user stories for a niche role (volunteers) and leave the users to guess whether or not the user stories for volunteer apply to other completely different niche roles.
As a developer being made to guess: "hmm NGOs want to add volunteers... does that mean NGOs want to add donors? or does the app show NGOs common available donors which they can decide to contact? if volunteers is a general example, then do NGOs want to set donors participation hours? do NGOs want donors to have participation hours even though that seems odd to me personally?? (they don't actually. hours does not apply to the donors and is specific to volunteers)" --> CONFUSING
Therefore, I do still think it's in scope.
Add person (or donor or partner) is a basic desire of a user yet it is missing from the user stories. Only volunteer adding is mentioned.