JIRA New Workflow Use Cases

Owned by James Renfro
Last updated: Apr 19, 2007Version comment
3 min read

 These are the conceptual units of the new framework


 
The idea is that a Story is tied to an Iteration. A Bug can also be tied to an Iteration, or even potentially a Trouble Ticket.

An Asset floats free of the Iteration and follows the code migration workflow. The Asset is a change in the code, one or more Subversion revisions.

Use Case #1: A simple story without a topic

  1. Sandra or Kirk creates a Story, SAK-999: Implement a Contact Us button at the top of SmartSite. They push this through to "Ready for Estimation"
  2. The developers estimate the Story at 18 story points and hand it back to the business side.
  3. The business side commit it to an Iteration. It goes up on the Wall.
  4. Thomas takes it off the wall, moves it to Begin Programming.
  5. He makes a change to the Portal code to display a link at the top of the page.
  6. Before committing this change to Subversion, he creates an Asset, SAK-1000
  7. He commits his code change to Subversion and puts SAK-1000 in his log comment so it will appear in the Asset's svn logs plugin inside of jira
  8. He links SAK-1000 as an Asset of SAK-999
  9. Then Iteration ends. He's done 4 hours of work, so he reduces the estimate on SAK-999 to 4 and changes the description to "Display a Link at top of Portal"
  10. He creates a new Story SAK-1001
  11. He estimates SAK-1001 as 14 story points and makes the description "Develop Contact Us application"
  12. He links SAK-1000 as an Asset of SAK-1001 - it's still linked to SAK-999 as well
  13. He completes this work and commits to Subversion with SAK-1000 in the log comment - all changes will be tied to the Asset
  14. The Iteration ends.
  15. The Asset gets moved to Testing ... then eventually rolls out to Producation.

Use Case #2: A more complex long term effort

  1. Sandra or Kirk create a Topic, SAK-2000: Course Management for 2.4
  2. The developers and the business unit get together to create a set of Stories, SAK-2001 thru SAK-2008, which break down the effort into workable chunks
  3. SAK-2001: Map Course Management to our Materialized Views is estimated at 40 story points and commited to an Iteration.
  4. Jon grabs it off the wall, begins writing hibernate mapping files, adding new java files as a sub directory of course-management
  5. Jon creates an Asset SAK-2010: Course Management Changes for 2.4, and attaches it as an Asset to SAK-2001, the Story
  6. He checks in his changes and labels the subversion log comment with SAK-2010 and SAK-2000, the Topic
  7. He marks the Story, SAK-2001 to Programming Completed.
  8. The Iteration ends.
  9. Kirk and Sandra commit SAK-2002 to the next Iteration, and the process repeats, with one (or more) Assets created for each Story.
  10. Once all of this work is done under the Topic, then we can look under Subversion logs tab in JIRA and see all of the revision changes
  11. Also, we can look under each Asset and see all the revisions that are tied to that Abbsset.
    • Note that the Asset should capture a reasonable unit of coding changes that can be rolled to Test, tested idependently, and then rolled to Prod.
    • The important distinction between Assets and all the other JIRA types is that the Asset goes to a real work unit of work, which has been committed to Subversion.

Use Case #3: A trouble ticket/bug fix

  1. ITExpress creates a Trouble Ticket, SAK-3000: User cannot unjoin Membership once joined.
  2. Mike Waid pushes this over to 'Sakai Team'
  3. James looks at the Foundation JIRA and sees that a bug fix exists in Foundation trunk that has not yet been moved over to our repository
  4. He creates a new Asset, SAK-3001 and links it to the Trouble Ticket - he could also create a Bug, link that to the Trouble Ticket, and then link the Asset to the Bug... that might be cleaner for a major change
  5. He merges the revisions from Foundation subversion into his local working copy of our codebase
  6. He commits this change and labels it in the Subversion log comment as SAK-3001, so it will appear in the Subversion jira plugin window for that Asset
  7. He marks the Asset as Queued for Testing
  8. He comments on the Trouble Ticket to indicate what has happened. (And potentially moves the Bug thru to Programming Completed, if applicable)
  9. The Asset gets pushed along through the migration path until it rolls to Prod.
  10. He comments on the Trouble Ticket to let ITExpress know that the change has been applied.