How We Work

Project principles

To maintain open communication as we gather additional user feedback, the Forest Service is working on the ePermit project would like to share the work we’ve done so far, both in narrative form and as a visual timeline. Our organization’s dedication to agile and user-centered design includes keeping our stakeholders up to date on our progress throughout each engagement; accordingly, we want every level of the Forest Service staff to be aware of what we’re working on and how that relates back to what we heard from you and the public.

As a reminder, these are the principles that guide our work:

• Human-centered design: Our projects are by the people, for the people. We design everything with the end user in mind. We start with user needs and then address stakeholders’ and management’s. Read more in our design method cards.

• Agile: We’re iterative, experimental, and failure tolerant. We don't plan two years of development before we start. As we work, we pay careful attention to what succeeds — and what doesn't. We quantify our work with metrics and feedback, which, in turn, informs our thinking and our next round of building. Read more in our agile guide.

• Open: Our projects are designed and built in the open. That means open source, open data, and open APIs. Working transparently helps us develop faster, make better decisions, gather meaningful feedback, provide code for many others to reuse, and keep costs low.

We’ve divided our summary into three main sections — parallel permit efforts, special-use permits, and Christmas tree permits — to provide a clearer, high-level view of the work we completed for each thread.

We hope that you find these updates useful; our intent is to highlight how our processes prioritize our users’ needs. We welcome your feedback on how future communication can be improved.

Agile Practices

The team:

• Uses sprint planning to commit to a set of stories achievable within a sprint
• Maintains and abides by a shared definition of done
• Maintains an open project board of planned, in progress, and completed user stories
• Works with the Product Owner to groom and break down user stories as the project permits
• Has an agenda for sprint ceremonies
• Regularly conducts sprint reviews to show working software and any other artifacts and get feedback on these from other team members as well as stakeholders or other interested parties
• Regularly participates in retrospectives

Delivery process

We apply a subset of the Scaled Agile Framework (SAFe) to guide our program structure, as described in Essential SAFe. We set goals and prioritize work in three month periods called "program increments," or PIs, and practice a number of SAFe rituals around this quarterly cadence.

How Designers and Developers Work Together

Either in sprint planning or as needed throughout the sprint assign people to work stories so that they are notified by GitHub.

• Add tasks for design work (mocks, research, etc)
• Add task for PO approval of design work
• Add tasks for dev work
• When design completes their tasks, they check the box and @ the PO in a comment.
• When PO approves, add comment so that others assigned will be notified.

Estimation with Story Points

The number in each column of the platform board indicates the the number of story points that have been committed. Our team generally works to keep 15-20 story points committed per two week sprint. During back refinement meetings, our team works together using planning poker to determine the number of points that a given issue should be assigned and adds the points to an issue within ZenHub. In addition to providing a general estimate on the level of effort to complete a task, determining the story points as an integrated team ensures that everyone is on the same page for the rough estimate a given issue will take to complete.

Story Lifecycle

Stories represent tactical increments of individually-valuable work deliverable by a squad within a single iteration, often an isolated change in functionality aimed at achieving a goal for a particular kind of stakeholder, whether customer, user, or operator/admin.

Stories progress through these columns:

Column Name	Definition	When Moved to Column
New issues	Where new tasks go until discussed with team	Any member on the team comes up with a new task
Icebox	A place for bright ideas that are not within scope at this time. Icebox items should be reviewed at the start of each quarter.	During a sprint planning session or program increment session, it’s determined the card is not within the current scope of the project
Backlog	Items that have been committed to during the current program increment.	Program increment planning sessions
Ready	Items that are committed to for the current sprint.	Sprint planning session
Blocked	Things only get moved here from the ready or in progress columns.	During a sprint planning session or sprint
In Progress	Tasks someone is actively working on.	Anytime during a sprint, any team member takes on a card from the ready column
Validation	Task is peer reviewed by another member of the team, prior to PO.	After a task is thought to be completed
Awaiting Acceptance	When product owner reviews work in staging to ensure user need has been met.	After a card is done, but not yet reviewed by the product owner
Ready for Master	Product owner moves card from review to this column to signify approval and that the work is ready to go live.	After the product owner approves
Done	Developer moves card after the code has been committed to master	After code has been committed to master
Closed	Issue is closed out	After Product owner confirms code in master is running properly in production

Lables

Design label -

• What’s it for?: Identifying tasks that have a significant design component``
• Who adds it?: Scrum Master or team member* ``
• When?: During sprint planning, refinement, or backlog grooming. *A team member might add this label if it’s a new issue they’ve created.``

Engineering label -

• What’s it for?: Identifying tasks that have a significant development component
• Who adds it?: Scrum Master or team member*
• When?: During sprint planning, refinement, or backlog grooming. *A team member might add this label if it’s a new issue they’ve created.

Sprint label -

• What’s it for?: Identifying the sprint in which the team has committed to completing the task
• Who adds it?: Scrum Master or Product Owner
• When?: During sprint planning

Project Gitflow and Release Management

• The main repository will be the USDAForestService/fs-open-forest-platform.

• The production deployment branch branch will be USDAForestService/master.

Merging Code:

• New pull requests will be created against the 18F/Dev branch with the naming scheme Issue-number-Subject, unless it is a hot fix.
• A developer will review open PRs against USDAForestService/dev before merging
• The PO will review what’s on staging moves to “Ready for Master” column upon approval
• When “PO Viewable” column is empty, devs open PR to move to master with light release notes
• The PO will approve any PRS that are from the USDAForestService/dev to 18F/master branch
• On PO approval, devs push to master
• Verify on production whenever possible/feasible