Hi,
Previously I've only been working in one team, but in multiple applications. Now I'm split between two teams and multiple applications per team and the teams are working a bit differently in Jira, but both are having a Kanban approach. Most of the team's work is to make a transformation from paper to digital so most of our applications are electronic forms the user fills in and at the end they sign it electronically and then it gets emailed somewhere. Historically we've always worked with the following Jira distinctions.
Never moved on the board
*****************************
Epic: A container for stories of a similar type (ie Accessability, Input fields). These have not been moved through the board as these containers have been static over time.
Moved from column to column on the board ("Ready for UX" | UX | "Ready for dev" and so on so going through all sub-teams (UX, AD, Dev, Test) of our team)
************************************************
Story: A use case (ie "Step 1 of the form") with requirements written like "Given X When Y Then Z). Basically its always an action the user take (press the button to go to step 2 of the form) which will make the system do something (display step 2 of the form)
Sub-task: One for each field under "Step 1 of the form" with requirements written like "Given X When Y Then Z)
Bugs: Even though these usually skip UX and AD
Moved from one sub-teams columns to Done (ie Ready for dev | Dev | Done)
*************************************************
Task: Anything that a sub-team is responsible for, but don't need any action in other sub-teams (Set up a repository, Talk to UX Lead about new icon standards)
Outside of the issuetypes we use
* Component: Name of the application (Survey X)
* Fix version: For Survey X it would be something like "SurX 1.3.2" (1 for major change, 3 for minor change and 2 for hotfix). Low number of hotfixes = quality in what we realese.
What I've missed in the structure above has been the user stories (ie "As a user I want to send survey X to HQ"). Reading through the Atlassian forum it seems like some are using the Epic issuetype for the user stories (Thread "Epic vs Story vs Task"). That way the Epic goes through the board, which seems nice as it gives a symbolic value. It think it would help with setting up functional testing as you can map that to the Epics.
Spontaneously I don't see a problem with using labels for "Accessability", "Input fields" etc.
Before I commit to the idea it would be nice to get some input from the community and how you look at these issues and which fields you use to help make it easy to find old issues.
Best Regards,
Vigfus
