Case notes serve as a running record of client contact as well as a location to keep track of any client information relevant to their treatment. Case managers are dedicated to serving the ever-changing requirements of their clients. As a result, case managers will keep track of clients’ progress, goals, and treatment responses in a case note.

1. Sintu Boro - UI/UX Developer
2. Nana Boakye - PM/BA
3. Akhil Sai Gunda - Data Architect
4. Asifa Mobeen - Microservices Developer
5. Mutunoor, Akshay Kumar - Data Architect
6. Samala, Harish Kumar - Quality and DevOps

A solution that drives the optimization of every facet of documenting components, evaluations, and encounters between patients and health professionals, evaluating the effectiveness of the services received by the patients, creating information visibility, promoting automated and streamline methods to identify and analyze customer profile in order to make precise and informed decisions.

Enable the delivery of a frictionless experience to a consumer, from self-service, feedback analysis to risk evaluation, automating the process, reducing manual paper-work, and enabling everyone in the healthcare access relevant information at the right time.

The link below contains the detailed user persona for the real stakeholders.

• Oana Stevens, an Urban Architect suffering mental health issues.
• Carolyn Adams, a Hospital Nurse, intended to become proficient in customization and optimization of EHR to improve daily workflow.
• Mary F. Overton, a Primary Care Physician, consistently providing high-quality care for patients, and help them stay healthy.

Deatiled User Persona (Link to Figma)

The product backlogs for the first iteration are stored in Pivotal Tracker and can be found here.

• All product backlog items are expressed as excellent user stories.

Every user story that we have built so far starts in the icebox as loose ideas followed by moving them out of the icebox estimating priorities for each of these PBI's.

• We then figure out the most important tasks to be accomplished in the upcoming sprint based on estimated priority and estimated points of the PBI.
• We decide on the iteration length in weeks, followed by tasks that can be accomplished within the time frame.
• With the help of PBI estimated points, we take into consideration the level of risk, repetition, and complexity.
• The PBI's that delivers high value with comparatively less complexity are prioritized first followed by PBI's with high value but high complexity.
• We try to take at max 11 possible points in a sprint. But with high value, high complex tasks we consider taking only 9 points.
• Based on the above details, we carefully consider PBI's for upcoming sprints.

• Product: Case notes (Web)
• Title:
• User story opening sentence:

Before adding a product backlog item to a Sprint backlog, as a team, we agree that it will be refined until:

• Story can be developed Independent from other stories.
• Refined to get a functional cohesion.
• If there are dependencies, they were refined and separated.
• One team can work on it with minimal or no dependencies on other teams.
• One team member can complete the work with minimal or no dependencies on others.

• The story was discussed with the team and they understand what to do.
• The Acceptance criteria is defined.
• There is a high level technical solution.
• The team has what they need to start working on the story but some details will be discovered during the development.
• A/B variants are defined.

• The priority in the backlog is clear.
• Prioritized using MoSCoW method.
• The Value of the story is quantified.
• The team understands Why we do this and the expected impact on the user
• The Role who obtain the value of the story is clear.
• The stakeholders (would) agree with the Acceptance criteria and value.
• It is clear if should be part of the next Product increment or MVP (minimum viable product).
• Hypothesis/experiment, expected outcome, metrics and measurement period is defined.
• Return of Investment: Stakeholders and PO know how much they will obtain with this story.
• As Role I want Feature so that Benefit.

• Planning poker session done with the team.
• Estimated in Tee-shirt sizes.
• Estimated in Story points by the team.
• All stories have similar size.

• Small: Estimation size less than or equal to __ points.
• It is not an Epic.
• It can be done in One Sprint.
• Refined to obtain 80% of its value using 20% of its effort: The minimum size that can reach value was achieved.

• The team understands how the story can be tested.
• Acceptance tests and examples are defined.
• Scenario-oriented Acceptance criteria Given-When-Then.

• Collect and analyze client information - 3

• Monitor case health - Medical Practioner - 3

• Record the content of the meeting - 3

• External data - 2

• Data Analysis tool - 2

• Query Assistance - 2

Average for Sprint 1 = 15

• Review Cheklist Options - 3

• Role-Based access - 3

• Time limit - 2

• Case History of patient - 2

• Self service - 2

• Monitoring a plan - 2

Average for Sprint 2 = 14

• Plan objectives - 3

• Feedback analysis - 2

• Quick & easy communication - 3

• Comment on cases - 2

Average for Sprint 3 = 12

• Review & comment on case - 2

• Notify follow-up appointments - 2

• Write, update, delete Access - 3

• Quick and easy - 3

• One on One conversation - 3

• Risk Evaluation - 2

Average for Sprint 4 = 15

Average (considering all the Sprints) = 15 points