Document the lifecycle of a user story

[natalia-fitzgerald]

Task

The purpose of this task will be to finalize the lifecycle of a user story in order to inform the user story template and definition of ready and done.

[natalia-fitzgerald]

@dan-padgett @angelcardoz
Here's my pass at the full life cycle of a user story, building on the discussions we've had about the story refinement stages and definition of ready. This process takes the user story from inception to completion. This process flow is meant to capture the broad brushstrokes of the process as opposed to the finer details.

Life cycle of a user story

1. Identify user need

• When a user need is identified, the product owner consults with relevant stakeholders and team members, and a draft user story is written.

2. Create user story

• Once the user need is verified and the draft user story is reviewed, the story is added to GitHub.

3. Introduce to the team

• At backlog refinement, the user story is introduced to the team. If prioritized, a team member is assigned to further refine the story.

4. Refine user story

• Draft acceptance criteria are written and validated with the team, using tools such as task analysis and design exploration to guide thinking.

5. Review with the team

• At backlog refinement, the refined user story and draft acceptance criteria are reviewed. When the story meets the definition of ready, implementation may begin.

6. Implement user story

• When the team is available to begin work, the user story is added to a sprint and implementation begins.

7. Complete user story

• The product owner reviews the implemented user story against the definition of done. If requirements are met, the story is complete.

[angelcardoz]

@natalia-fitzgerald, what do you think of adding a number to each stage? For example, 1) Identify user need and 2) Create user story? I think the number will make it easier to reference the stage. For example, I was chatting with Dan about the "Review Filing" user stories and I wanted to say that certain stories were moving to the "Refine user story" stage, but didn't have an easy way to reference the stage; such as, "story #307 is now in stage 4".

[dan-padgett]

@natalia-fitzgerald I like how this is coming along. As you've mentioned in a chat, there's likely some design work that will get done during refinement if design owns the ticket. But I think that it's fine to capture that in a UX ticket: i.e. if design takes on refinement for a story, then we create a ticket in this repo for that task, and list out any design work that will be done as a part of that process. What do you think about that way of keeping design work visible?

[angelcardoz]

To make the diagram easier to follow, here's an example using [Story] See summary of completed filing #309.

Identify user need
The ability to review submissions is a common expectation in many systems. The product owner, considering this inherent user need and the precedent of a similar feature in HMDA, worked with the UX team to draft a user story: "As a filer, I want to see a summary of my completed filing, so that I can view the data filed with the CFPB."

Create user story
Once the product owner and UX team were satisfied with the final wording, the product owner added the story to GitHub and flagged it to the scrum master for inclusion in the next backlog refinement session.

Introduce to the team
During backlog refinement, the user story was introduced to the team. Team members provided feedback to clarify the wording and ensure alignment with the user need. After incorporating these suggestions, the story was assigned to the UX team for further development, focusing on design and usability considerations.

Refine user story
The UX team met with the product owner to debrief, discuss next steps, and explore options. To help visualize these options, the UX team created draft designs, illustrating how a summary of the completed filing might appear to users. The UX team drafted initial acceptance criteria, ensuring the story captured both functional requirements and user expectations. Both the draft designs and acceptance criteria were prepared for introduction during the upcoming dev-design sync to gather feedback and support further refinement.

Review with the team
At a future backlog refinement session, after dev-design sync, the refined user story along with the finalized acceptance criteria and updated draft designs, will be presented to the team. The team will assess the story against the definition of ready, providing any final feedback to ensure clarity, feasibility, and alignment with the user need before it is prioritized for implementation.

Implement user story
Once the user story meets the definition of ready, it will be prioritized by the product owner and scheduled for implementation. The UX team will work on the story at least one sprint before developers, focusing on finalizing the mockups and writing the content. These deliverables will serve as the blueprint for developers. Once the development team is ready, they will break the story into actionable tasks, including front-end development, back-end development, and further collaboration with the UX team to refine the user experience during implementation.

Complete user story
Once the user story is implemented, the UX team will confirm that the functionality works as intended, and the feature aligns with the designs. Finally, the product owner will review the completed work against the definition of done and ensure that all acceptance criteria are met. If any adjustments are required, they will need to be addressed before the story is marked complete.