You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a form-filler user, I feel overwhelmed by the large number of items in the navigation sidebar. I want to feel like the application is doable for me and that I can find my way back to a specific question if I need to change something. (Should we consider only showing page titles the user has interacted with so far? Maybe plus a %age done progress bar?)
Context
Optional: Any reference material or thoughts we may need for later reference, or assumptions of prior or future work that's out of scope for this story.
[ ]
Acceptance Criteria
Required outcomes of the story
Form filler users do not feel overwhelmed from the moment they begin
Form filler users can easily get back to a question from a previous page they want to update
Research Questions
Optional: Any initial questions for research
How do form builder/filler needs for navigation differ?
Are pdf page # references the best navigation "landmarks" for form builders or is there something else that will accomplish quick navigation when beginning work on a draft?
Tasks
Research, design, and engineering work needed to complete the story.
Design mocks new navigation features, including potential enhancements/items to test, focus is on learning
Engineering determines how much builder/filler page nav components can/should overlap under the hood
The "definition of done" ensures our quality standards are met with each bit of user-facing behavior we add. Everything that can be done incrementally should be done incrementally, while the context and details are fresh. If it’s inefficient or “hard” to do so, the team should figure out why and add OPEX/DEVEX backlog items to make it easier and more efficient.
Behavior
Acceptance criteria met
Implementation matches design decisions
Documentation
ADRs (/documents/adr folder)
Relevant README.md(s)
Code quality
Code refactored for clarity and no design/technical debt
Adhere to separation of concerns; code is not tightly coupled, especially to 3rd party dependencies; dependency rule followed
Code is reviewed by team member
Code quality checks passed
Security and privacy
Automated security and privacy gates passed
Testing tasks completed
Automated tests pass
Unit test coverage of our code >= 90%
Build and deploy
Build process updated
API(s) are versioned
Feature toggles created and/or deleted. Document the feature toggle
Source code is merged to the main branch
Decisions
Optional: Any decisions we've made while working on this story
The text was updated successfully, but these errors were encountered:
Overview
As a form-filler user, I feel overwhelmed by the large number of items in the navigation sidebar. I want to feel like the application is doable for me and that I can find my way back to a specific question if I need to change something. (Should we consider only showing page titles the user has interacted with so far? Maybe plus a %age done progress bar?)
Context
Optional: Any reference material or thoughts we may need for later reference, or assumptions of prior or future work that's out of scope for this story.
Acceptance Criteria
Required outcomes of the story
Research Questions
Tasks
Research, design, and engineering work needed to complete the story.
Definition of done
The "definition of done" ensures our quality standards are met with each bit of user-facing behavior we add. Everything that can be done incrementally should be done incrementally, while the context and details are fresh. If it’s inefficient or “hard” to do so, the team should figure out why and add OPEX/DEVEX backlog items to make it easier and more efficient.
/documents/adr
folder)README.md
(s)Decisions
The text was updated successfully, but these errors were encountered: