The Development projects in JIRA use a a lightweight style of Agile Scrum management to allow us to efficiently and effectively plan and release software on a regular basis. To support this, it is important that the following procedures and conventions be followed to avoid miscommunication.app
This document currently applies to the ROS, RA, and SSO projects.ide
First, read this: https://en.wikipedia.org/wiki/Scrum_(software_development)ui
When creating a ticket, the important decisions are:this
Once you've figured these out, all that remains is to write a concise, descriptive, and comprehensive ticket.atom
Something's not working the way it is supposed to. Bugs should be a description of what is not working, how to reproduce the bug, and what the behavior is expected to be (not what you want it to be).idea
A User Story is a business language description of a small functionality requirement within the application. The Wikipedia article contains some examples of formatting and some philosophy behind the use of User Stories.spa
During the Sprint Planning process, the development team will estimate the difficulty of User Stories based on Story Points; anything that is too complex (i.e. more than 13 points) will need to be broken down into multiple User Stories, which can be grouped using an Epic. A 13 point story represents an estimated 1 day of work, which is the absolute upper limit of the complexity that should be covered by a single Story.rest
Examplescode
Because user stories are intentionally high level and intended to capture core business functionality, we will use the "Requirement" ticket type to capture functional and non-functional requirements around a User Story. For a story to be completed, all requirements must pass testing.component
Design elements belong to User Stories, and describe a visual element, as created by the Creative team to fulfill the User Story and its requirements. Design elements should be atomic and easily testable, such as a button or a widget. For larger-scale design constructs, the layout and the sub-elements should be broken down into separate design elements.
Examples
A behavior describes the results of a given action taken by a user.
Technical tasks are used by the development team to track non-user-facing elements of completing user stories, such as database and code changes.
These apply to User Stories about new features; they are intended to roughly capture the business value of a given User Story to the company. These do not strictly correlate to the Rank of a ticket within the project, but will be used to influence Sprint planning.
|
Priority
|
Description
|
|---|---|
| Blocker | Don't use this for new features. |
| Critical | Don't use this for new features. |
| Major | This feature is going to rock the socks off of our Users, or measurably reduce our support burden |
| Minor | This is definitely neat. |
| Trivial | This would be nice to have, but is not expected to be earth shaking for us our users. |
|
Priority
|
Description
|
|---|---|
| Blocker | Production is down or cannot complete basic functionality. Fix timeline: Drop Everything. |
| Critical | Production performance or behavior is substantially impaired, but workaround are possible to continue business. Fix Timeline: hotfix, same day. |
| Major | This bug results in a loss of function. Fix timeline: hotfix, 1-2 days. |
| Minor | This bug can be worked around but results in operational friction. Fix timeline: 1-2 releases. |
| Trivial | Removing this bug would be a nice to have. Fix timeline: who knows. |
Task effort is estimated using "points". These are an arbitrary representation of the relative perceived value or difficulty of a ticket. Points are used because in practice humans are terrible at estimating things. The point scale is based on a rounded Fibonnaci sequence, representing the increased uncertainty that goes along with estimating larger chunks of work. In general, User Stories worth more than 13 points are considered to be too complex to be accepted for a Sprint. Story point assignments are at the sole discretion of the Development Team (this includes Creative).
|
Points
|
Approximate Meaning
|
|---|---|
| 1 | Trivial change requiring minimal effort to implement |
| 2 | Minor change |
| 3 | Need a bathroom break. |
| 5 | Caffeine required. |
| 8 | Roughly equivalent to a half day of work. |
| 13 | This is a full day project for a pair of developers |
| 21 | This is too big, but close to being doable |
| 100 | I can't even. |
Documenting new Stories, Epics, Bugs, and Requirements in JIRA is an ongoing process. Over time, these tickets will build up what is known as the Backlog, which is essentially a to-do list for software development. The Backlog is maintained by theProduct Owner, which may initially be a shared responsibility (implementation pending). The Product Owner is responsible for prioritizing the backlog based upon input from various stakeholders, including Customers, Creative, Biz Dev, and Development.
Every two weeks a Sprint Planning Meeting will be held to determine what we will be working on for the next period of time. This meeting will last no longer than two hours, and will accomplish the following:
User stories that are "too big" will be sent back to the Reporter to be broken down, usually into several stories as part of an Epic.
Each Sprint will last for two weeks, during which the Development Team (which includes software developers and designers) will work to Burndown the Sprint Backlog. This is tracked on JIRA via the "Work" pane of an Agile Board.
During the course of a Sprint, ideally no new Stories are added; in practice, bugs and urgent requirements will arise. When new items are added to an in-progress Sprint, a mini Sprint Planning meeting will be held to review the scope of the Sprint. As a result, other Stories may be removed from the Sprint to make room.
Reporters of User Stories ("Customers" in Agile parlance) are encouraged to review Stories marked as complete by Development during the course of the Sprint. In general, the development team will deploy nightly builds during the Sprint process (as per usual, availability and uptime guarantees are not made for the development server).
At the Sprint Review, the Development Team will:
The Sprint Retrospective allows the team to make continuous process improvements, and focuses on:
Each Sprint results in a Potentially Shippable Increment (PSI). Our current policy is to ship every PSI that we produce after appropriate testing. Because the testing process can vary in length, the time between releases may not match the Sprint period.
One flaw with the current Rosie testing procedure is that it is very disruptive to the ongoing development process, as questions and regressions tend to distract developers from concentrating on new work. To avoid this going forward, the testing process will now take a more measured approach:
As we continue to robustify our automated testing procedures during the development process, the goal is to greatly reduce regressions and make most testing about validating that User Stories are properly implemented. Initially, it is expected that this testing procedure will take between 2 and 5 days to fully complete.