Project management for the SBL (Small Business Lending) project.
The source code for SBL's software is spread across multiple GitHub repositories. We use GitHub Projects to manage the work across these repos.
Our project is up at:
We work in two week sprints. The current sprint is viewable on the Sprint tab of SBL Project.
We use User Stories to define the features we will implement for SBL. These user stories are represented as GitHub issues, labeled as story. During our Sprint Planning meetings, we select User Stories for the upcoming Sprint that meet our definition of ready.
In order for a user story to be considered "ready", and brought into a sprint, the team must agree that it meets the following criteria.
- All dependencies have been identified.
- UX requirements are complete, with UX resources linked to the user story.
- Acceptance criteria is complete.
- The story can be accomplished in a single sprint.
In order for a user story to be consider "done", and the issue closed, it must meet the following criteria.
- All acceptance criteria have been met.
- All UX requirements have been met.
- There are no known defects.
- Unit test coverage > 85%.
- Is deployed to the development environment.
- Documentation has been updated (if needed).
We use Epics to represent larger bodies of work that span multiple user stories across multiple sprints. These epics are represented as GitHub issues, labeled as epic. We use these issues for the initial research and discussion before we take on the underlying user stories.
We also do most of our UX and design on epic issues. This work includes producing wireframes and mockups, gathering background information, and user research. We don't start work on any user stories until this upfront work has been completed.
We use Milestones as a means of grouping our epic issues. We use these for grouping our work into larger initiatives. This is especially useful in our project Roadmap view. view
We use GitHub issues to track our development tasks as well. These issues live in separate repos alongside their corresponding code. These issues will frequently be associated with story issues, but can also be indepedent tasks, such as bug fixes. These issues do not follow any consistent labeling scheme as each repo has different needs.
- design-system-react - React implementation of CFPB's Design System
- regtech-api-commons - Shared FastAPI components for CFPB's RegTech services
- regtech-data-validator - Data validation tool for CFPB's RegTech services
- regtech-deployments - Shared Kubernetes resources for CFPB's RegTech services
- regtech-mail-api - REST API for sending emails
- regtech-user-fi-management - REST API for user and institution data in CFPB's RegTech systems
- sbl-filing-api - REST API for filing SBL submissions
- sbl-frontend - Web frontend for the CFPB's SBL filing system
For local development, we use docker compose to run the supporting services. Please refer to LOCAL_DEV_COMPOSE for details.