-
Notifications
You must be signed in to change notification settings - Fork 3
Issue Tracking
- User Story Development
- Issue Creation Best Practices
- Pull Request Titles
- Bug Prioritization Policy
- Tracking Issue Backlog with Zenhub
- References
The Agile equivalent for requirements, user stories are intended as a more user-friendly, user-focused method for describing the what, why, how, and who for system features and expected functionality.
A concise, written description, of a piece of functionality that will be valuable to a user (or owner) of the software.
A good user story is:
- Independent
- Negotiable
- Valuable to users or customers
- Estimatable
- Small
- Testable
As a , I can so that
- Role - the user role for the story. e.g. user, developer, node operator, systems administrator
- Goal - what the user is trying to accomplish
- Motivation - why the user wants to accomplish it
- As a user, I can backup my entire hard drive. (Epic)
- As a power user, I can specify files or folders to backup based on file size, date created and date modified.
- As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.
- Provide the criteria to determine if the story has been correctly and fully implemented.
- Developed before stories are implemented to provide guidance to developers
Why the user wants to accomplish it
For example: As a user, I want to be able to view my Order History **so that I can check on the status of previous purchases.
Given When I perform Then I expect
For example:
Given that I have previously created an account
When I attempt to create an account
Then I expect to receive a notification that I already have an account
Then I expect to be forwarded to a login screen
- States intent “what” not solution “how”
- ✅ The customer can choose the shipping method
- ❌ The customer can select the shipping method from a drop‐down
- Independent of implementation
- Clear unambiguous language
- Rather high level (not every detail is documented)
The PDS has used the article “Naming Guide For Task, Bug, and User Story Titles” for enhancement and bug issue creation best practices.
Here are some high-priority best practices we really want to try to follow:
- In general, for enhancements and bugs, at minimum, start the title with a verb (e.g. Ingest some data from somewhere or Update this page with some change)
-
Title should be able to tell someone what was fixed or completed
- We plan on using these issue titles for generating changelogs and report automatically
- Use autolinked references wherever possible for traceability
- Using references is a HUGE benefit in streamlining productivity, project management, provenance, and requirements/test traceability.
We now use GitHub automated release notes, which use PR titles to generate. Since our Release Notes are "user-focused", let's try our best to make these titles "user-friendly", for example:
- New utility to validate references using the registry
- Fixed bug with handle members of a collection (
/products/{lidvid}/members) - etc.
PDS follows a bug/defect prioritization policy that is similar to that used by flight projects, with a twist for the needs of issue tracking.
| Consequence | ||||||
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 5 | LOW | MEDIUM | HIGH | CRITICAL | CRITICAL | |
| 4 | LOW | MEDIUM | HIGH | HIGH | CRITICAL | |
| Likelihood | 3 | LOW | MEDIUM | MEDIUM | HIGH | HIGH |
| 2 | LOW | LOW | LOW | MEDIUM | MEDIUM | |
| 1 | LOW | LOW | LOW | LOW | MEDIUM |
| Level | Description | Consequence Definitions |
|---|---|---|
| 5 | Very High | Mission Failure |
| 4 | High | Significant reduction in mission return |
| 3 | Moderate | Moderate reduction in mission return |
| 2 | Low | Small reduction in mission return |
| 1 | Very low | Minimal reduction in mission return |
| Level | Description | Level Definition | Percentage (%) |
|---|---|---|---|
| 5 | Very High | Almost certain | 70% < X ≤ 100% |
| 4 | High | More likely than not | 50% < X ≤ 70% |
| 3 | Moderate | Significant likelihood | 10% < X ≤ 50% |
| 2 | Low | Unlikely | 1% < X ≤ 10% |
| 1 | Very Low | Very unlikely | X ≤ 1% |
We use Zenhub to visualize all our tickets across all our NASA-PDS Github repos. Because of the large number of projects and issues, the issues are organized into several different Kanban boards for hopefully more clear understanding of priority.
The product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
These backlogs should be organized and prioritized so the team knows what should be considered heading into the next release planning effort.
Here are the product backlog boards for the currently active PDS projects:
| Product / Project Name | Workspace | Applicable Repos |
|---|---|---|
| Registry Services | Product Backlog - Registry + API | pds-registry-app, archive-analytics, harvest, pds-registry-common, pds-registry-ingest, pds-registry-mgr-elastic, pds-registry-mgr-solr, registry-api-service, pds-api-service, pds-api-pythonlib, pds-api-javalib, pds-api-client, pds-api, api-search-query-lexer, pds-api-notebook, registry-ci, supplementer |
| DOI Service | Product Backlog - DOI Service | pds-doi-service, pds-doi-ui |
| PDS Web Modernization | Product Backlog - PDS UX | PDS.nasa.gov-UX, archive-viewer, pds-wds, pds-wds-react, pds-wds-web |
| DevOps | Product Backlog - DevOps | roundup-action, gh-action-pds4-ldd, git-ping, github-actions-base, pds-github-util, pdsen-corral, pdsen-operations |
| Data Stewardship | Product Backlog - Data Stewardship | validate, pds4-jparser, pds4-information-model, pds3-product-tools, PLAID |
| PDS Operations | PDS Operations | pdsen-operations |
| Everything else | Product Backlog - The Rest (filter by individual repos) | everything else |
| Portfolio Backlog (view only) | Portfolio Backlog (view only) (filter by individual repos) | All |
The release backlog is the subset of themes and/or specific tasks from the product backlog(s) that a team targets to deliver during a release. These are decided upon during the release planning effort, and can be found in the Release Backlog swimlane of the Product Backlogs.
The sprint backlog is the subset of product backlog that a team targets to deliver during a sprint in order to accomplish the sprint goal and make progress toward a desired outcome.
Sprint Backlog Workspace : Team should use this board to provide status on current work and look for the next items to work on.
Copyright © 2021-2024 California Institute of Technology.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.