watonomous.github.io
[ Electrical Division : JIRA Workflow ]
Created by [ Kash Pirani], last modified on May 06, 2020
Overview
The Electrical Division is not an agile team, but still follows some agile methodology. We do not follow true sprints, but instead follow rough two-week dev cycles. This is because most electrical projects are on-going - without a concrete end goal. For example, power systems exists to maintain and improve the electrical systems within the car. They do not have a "product" they are working towards, nor specific competition challenges they are solving. The following workflow has been created with this in mind. It is designed to be as simple as possible, while promoting good working practices across the entire division.
Epics, Stories, Tasks
JIRA has the concepts of Epics, User Stories, as well as Tasks and Sub-Tasks.
Epics are typically used to describe large overarching goals/projects for the team. These typically span multiple dev-cycles and are broken down into a series of tasks and user-stories that better define the work. They are used to capture broader system requirements, and provide a good visual representation of the progress made on a large task. Epics are broken down into stories and tasks.
User Stories are used to summarize tasks in plainer non-technical language. They are intended to prove insight into the user experience, and hopefully frame the issue around the end-user. To this as, stories typically follow the format "As a <person> I want <to do this thing>, <so that xyz can happen>". Stories are less broad than epics and will describe a concrete task, such as "As I pipeline operator I want the ability to turn telemetry on and off from a GUI, so that I can better control the pipeline." Stories are typically broken down into individual tasks.
Tasks are tickets that describe a short and concrete feature or action item that needs to be done. They should contain detailed requirements, a definition of done, and any relevant design documents. Ideally, a developer should know exactly what they are supposed to do after reading through a task description. Typically, a handful of tasks can be completed each dev-cycle. Larger tasks can be broken down into sub-tasks
Sub-tasks are the smallest possible "unit" in JIRA. They describe simple concrete action items in detail, and like tasks also have a definition of done, a set of requirements, and relevant design documents.
Ticket Structuring
In the electrical division we only make use of Epics, Tasks, and Sub-tasks. The hierarchy of tickets is as follows:
Epics - define large projects that may span multiple dev cycles. Ex) Modularize CAN code. Epics are broken down into individual tasks.
|______ Tasks - describe in detail the components that need to be created in order to fulfill the requirements of the epic.
|______ Sub-tasks - break down large tasks into smaller, simpler steps.
\
Important Note: Tasks can exist independent of an epic. If a feature needs to be implemented that is not part of a larger project, then a task can be created for that feature alone. However, a sub-task should not exist unless it breaks down a larger task. Furthermore, no epics should exist unless they are tied to concrete tasks.
[Why do we not use stories?] As described above, a user story is intended to frame an issue from the perspective of the end user. It is important to note that the electrical division does not do "product-driven" work - in other words we typically work on hidden embedded systems or projects that are not meant to be interacted with by a user. While it can be argued that electrical division members are the "users", we are also the developers - so it is redundant to spend the extra time writing user stories from our own perspective. Adding stories into our workflow would only complicate the ticket structuring and increase the time it takes for managers to layout dev-cycle plans - all without any noticeable benefit.
\
Issue Workflow
\
[
{.confluence-embedded-image
height=”400”}]{.confluence-embedded-file-wrapper
.confluence-embedded-manual-size}
Issues in JIRA transition through multiple states over their lifetime, and [it is the responsibility of the developer to update the state of their ticket as they progress through the task.]
Issues start in the Open state upon creation → When a developer has started work on it, they should transition the ticket to the In Progress state → Upon submitting a Merge Request or reviewing their work in person, the ticket should be moved to the In Review state → If their work was approved, the ticket should be moved to the Done thus ending the lifecycle of the ticket. If there is feedback to address, it should be moved back to the In Progress state.
[What is the point of the In Review state?] The review state indicates that an issue is under both review and validation. As described in the Git Workflow document, reviewing code and other work completed is integral to the success of the team. This state allows developers to signal that they have completed the first draft of their implementation and now are seeking feedback. When browsing the issue boards, it makes it easy to see which tickets are pending review and reminds managers and directors to review completed work if they have not already done so. This state is especially helpful when doing dev-cycle planning, as it allows the sub-teams to differentiate between tickets that are "still being worked on" and tickets that are close to completed but just need additional review.
\
Priorities
The Electrical Division only makes use of two issue priorities - High, and Low.
Tickets that are high priority for a given dev-cycle should be designated as high priority, while tickets that aren't critical for the upcoming test-track (or next milestone) should be marked as low priority.
[Why don't we have more priorities (like a medium priority)?]
- The first reason it that is over complicates planning out a dev-cycle. All tasks can be sorted into two categories, issues we need to get done first and issues that we can leave on the back burner for a bit.
- After all high priority tasks have been completed, low-priority items can be discussed re-prioritized to high priority at the next planning meeting.
- If this is the case, then there is no need for a "medium" priority. Developers will always be working on the high priority items, and will re-prioritize items after completing all critical steps in the dev-cycle
\
Attachments:
Electrical
Workflow.PNG (image/png)\
Comments:
+———————————————————————–+
| [] |
| |
| Something to consider: Sprint Use |
| |
| {.smallfont align=”left” style=”color: #666666; width: 98%; margi |
| n-bottom: 10px;”} |
| 
|
| Posted by sktuer at Jan 21, 2020 23:46 |
| |
+———————————————————————–+
Document generated by Confluence on Nov 28, 2021 22:40