-
Notifications
You must be signed in to change notification settings - Fork 3
Issue Tracking
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
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.
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 Github.com repositories.
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.