Things to consider while communicating with stakeholder or PM

- understand the business objective:

- discuss the high-level business objective or problem the user story aims to
address
- understand the "why" behind the feature
- what business value or benefit is expected?
- user needs and personas:
- dentify the primary users and stakeholders involved
- understand their needs, goals, and pain points
- define user personas if applicable
- acceptance criteria:
- work closely with the project manager and stakeholders to define clear
acceptance criteria
- make sure they align with the business goals
- constraints and dependencies:
- discuss any technical or business constraints that might impact the
implementation of the user story
- identify dependencies on other features or external systems
- prioritization and impact:
- understand the relative priority of the user story compared to other items in
the backlog
- use case scenarios:
- discuss potential use case scenarios or workflows related to the user story
- understand how users will interact with the feature
- user interface (UI) considerations:
- if the user story involves changes to the user interface
- discuss UI design requirements, including wireframes or mockups
- ensure a shared vision of the expected user experience
- data requirements:
- if data is involved, clarify the data sources, data structures, and any data
transformations needed
- error handling and edge cases:
- discuss how errors and edge cases should be handled
- what error messages should be displayed
- what should happen when unexpected situations occur?
- regulatory and compliance requirements
- determine if there are any legal or regulatory requirements that need to be
addressed in the user story
- testing and quality assurance
- discuss testing requirements and quality assurance processes
- determine what should be tested and how it should be tested
- definition of done
- what it means for the user story to be "done."
- this might include criteria such as code review, testing, and documentation
- dependencies and risks
- identify any potential risks or dependencies that might affect the successful
completion of the user story
- discuss mitigation strategies
- performance expectations:
- response time - specify the maximum acceptable response time
- throughput - the rate at which the system can handle a certain number of
requests or transactions per unit of time
- scalability - how the software should scale as the user base or data load
grows. specify when and how additional resources (e.g., servers, databases) should
be added to maintain acceptable performance.
- concurrency and load handling - the maximum number of simultaneous users or
transactions the system can support
- latency - the delay between a request and the corresponding response
 - load testing requirements - specify the load testing scenarios that should be
performed to validate performance expectations. Describe the testing environment,
including the number of simulated users or transactions and the duration of the
test.
- response time under load - clarify how response times should behave when the
system is under heavy load. For example, define the maximum response time during
peak traffic hours.
- peak load handling - describe how the system should perform under peak load
conditions, such as during a product launch or a major marketing campaign. Define
the expected behavior and performance during such events.
- performance monitoring and reporting - define the metrics and key performance
indicators (KPIs) that should be continuously monitored. Specify how performance
data should be collected, logged, and reported.
- security and performance - consider the impact of security measures (e.g.,
encryption, authentication) on performance and specify the acceptable trade-offs
between security and performance.

Things to consider while creating a ticket

- create small user stories as possible with 3-7 acceptance criteria
- the acceptance criteria should be about what is needed but not how to do them
- the acceptance criteria should be clear, specific and testable.
- if there is a flow, the create a diagram and put it into the task instead of
writing it with words
- do not mix backend and front end acceptance criteria, put them in seperate
tickets