Partial project sprint and release roadmap
St. Luke's University Hospital Network Mobile App
Product owner and UX/UI Guidance
At the time of engagement, St. Luke's University Health Network (SLUHN) had an existing app that allowed users to find doctors and office locations. Their goal was to expand the feature set to provide scheduling of appointments via Clockwise and doctor.com APIs, patient health records via Epic MyChart SDK, and virtual doctor visits via American Well SDK.
The project goal was to bring together multiple disparate systems and databases, while creating a seamless front-end experience for the end-users who interacted with app.
My role on this project was to act as an agency-side product owner championing human-centered product decisions.
- Facilitation of requirements gathering with the client-side product team
- Coordination with client-side product owner for requirements clarification
- Guidance of the UX and UI design resources
- Running daily agile scrum stand-ups and regular sprint planning meetings
- Final acceptance testing of user stories and release candidates
Google Slides, Google Draw, JIRA, Confluence, Sketch, Invision, Zeplin, GoReflect
app store releases
After initial requirements were elicited from the client then captured in JIRA as epics, an initial feature roadmap was defined.
Constraints being worked within:
- Fixed price contract
- Fixed release milestones
- Fixed features per release
- Sprint X: Systems analysis
- Spring X+1: UX/UI definition
- Sprint X+2: Backend dev
- Sprint X+3: Frontend dev
- Sprint X+4: QA & acceptance
- New requirements would be captured in the backlog
- Backlog would be groomed as business priorities evolved
- Roadmap would be adjusted as needed prior to sprint planning meetings
Requirements Gathering and System Definition
Diagrams were employed to guide requirements clarification meetings for more complex features.
This allowed the team to:
- Identify gaps in the user's feature journey
- Record a shared understanding of how the system in question would work
- Contextual annotation regarding the user experience
- Contextual annotation regarding technical details like systems accessed and data sources required
Capturing Requirements for UX
During requirements gathering feature requirements were captured using user stories within JIRA for use by the Lead UX Designer when ideating and creating wireframes.
Wireframe client review sessions were twice per week (aggressive) on a set schedule and used to:
- Validate system understanding
- Flesh out more granular feature requirements
- Begin capturing details necessary for dev user stories
Observational User Testing
As the roadmap progressed and features were defined in wireframe form we would execute testing sessions to verify usability of the designs. Participants were recruited from customers of SLUHN, as well as their main competitor.
Testing was done:
- In a one-on-one setting with clients watching from an observation room
- Following an established script that would evolve as the sessions progressed and the client provided feedback
- Using two low-fidelity InVision prototypes for A/B testing feature concepts with participants
Creation of Development User Stories and Supporting Artifacts
Highly detailed development user stories were created for each feature.
I worked closely with the on-shore solutions architect to validate the details and size of each story prior to sprint planning meetings with the dev team. Stories were modified and/or broken down as needed.
Each story was linked to supporting artifacts:
- Wireframes with final copy integrated
- Screen flows to visually document feature logic
- Style guide and UI comps (if applicable)
- Other supporting documents as required
As a natural extension of my role as product owner, I assisted in guidance of our UX and UI resources as necessary.
Method used to capture UX and UI for the dev team:
- Wireframes were developed using a three-level atomic design system to create atoms (elements), molecules (reusable collections of atoms), and organisms (collections of molecules)
- Wireframes were created for each screen and state of the screen
- Final copy was captured within the wireframes, eliminating the need for a copy deck, to make the dev process more efficient
- Screen flows were created for each feature
- Wireframe annotations were captured within development user stories using JIRA
- UI styleguide was created based on the atomic design system
- UI comps were created only for screens that could not be easily created using the styleguide
- Styleguide and comps were stored within Zeplin so the dev team could access measurements and assets as needed
Guiding Agile Scrum Development
In my role as product owner I was responsible for guiding the development team on execution of the experience vision.
This includes, but was not limited to:
- Leading daily stand-ups, sprint planning and sprint reviews
- Answering or facilitating answers to story questions
- Final acceptance testing of user stories
- Our "definition of done" required my testing and acceptance of each story, task and spike
- Smoke testing on release candidates
Though we had a large amount of time for the project there was an equally large amount of work. An aggressive timeline and constant unknowns made the project challenging each day.
- Agile scrum is tough in an agency environment
- When there is a fixed cost, fixed scope and fixed timeline there is no room for ill-defined requirements and the inevitable scope creep that results
- Rapid design sprints need a foundation of fully fleshed out technical feasibility evaluations and feature definitions
- In the absence of this, design review meetings turn into forums for the client team to discuss and identify gaps that brings design iterations to a halt while answers are found
- The right people with the proper titles need to be in the room when feature discussions happen
- Ideally these people are identified and engaged earlier in the project and prior to implementation of features that will affect the daily workflows
- Features are best developed when broken down so that each sprint results in a deliverable portion of the product
- By attempting to implement full epics during a sprint, those epics were often not completed and would span multiple sprints, making it impossible to calculate team velocity