Types of Tasks
There are four basic classes of tasks that the Mobility project uses to govern its work. Each is indicated by the use of a keyword at the beginning of its summary field to make it easy to search and sort tasks by these classifiers.
Research tasks are boxes of time during which a developer will be asked to research a specific technology or idea. The deliverable for a research task is a written report or recommendation on the subject which should be attached to the JIRA so it can be easily found by anyone on the team searching for it.
Development tasks are the core JIRAs for defining and executing Mobility work. Dev tasks are used for new feature requests or enhancement requests to existing functionality. They should include detailed requirements describing the transactions involved and all error states that are reasonable to expect.
Bug tasks are used to capture the details of defects within released versions of Mobility. Bug tasks should include specific instructions for recreating the bug as well as details about the platform the bug was experienced on (operating system, native v. browser, browser type, network type, etc). Bug tasks are evaluated for priority and execution the same as every other task. Just being categorized as a bug does not make a task more important any other.
A quick win is a special type of task that should only be created by a member of the developer team. The purpose of the quick win is to allow any developer that happens to identify a bug or performance improvement that is trivial to fix the ability to capture the work and fix it without waiting for the task to be reviewed, estimated and assigned. A task is considered a quick win when the code changes and unit testing to resolve the problem will take less than 30 minutes of developer time.
All work for the Mobility project will follow the following process.
- Create a JIRA task describing the enhancement or bug. Be as detailed as possible.
- Twice weekly all new JIRA tasks will be evaluated by members of the development team for the following:
- review of requirements for completeness and requesting additional information as necessary.
- a high level tech design for the solution to ensure that it will fit well into the Mobility framework.
- a high level estimate of effort necessary to complete the work and accompanying unit tests.
- assignment of a priority based on the parameters for project growth set by the project board and/or services council.
- assignment of a target release that the feature or bug will included in.
- Every Friday work will be assigned so that every developer has up to three tasks assigned to them.
- Two tasks that are either bug fixes or new features
- One task that is categorized with the component label technical debt
- Developers in need of additional work more frequently can request more from the project manager or choose items from the planning column of the current Sprint's planning track on the JIRA Agile board for the project.
- All hours worked on JIRAs should be logged as Time Spent on that JIRA.
- When a task is completed it should be marked Resolved in JIRA so that the release manager can include in into QA builds for testing.
- Defects identified in a Resolved task should be noted in the comments section of the JIRA and the task re-opened and reassigned back to the developer for correction.
- Defects identified in QA builds that are not directly related to an active JIRA task are bugs and should be captured in a new JIRA so they can enter the process.
- When the features of a planned release are tested and approved then a new Mobility version will be released containing those features and bug fixes.
- The release manager will close all resolved tasks related to the release.
- The release manager will update the JIRA project to indicate the release in the project timeline.