IT Area - Guidelines_V1 - EN
Structure and Operational Management in Jira – IT Area
Overview Toolchain: Discovery to Delivery
A structured six-phase process designed to transform business opportunities into real, traceable initiatives, fully aligned with company strategy.
| Phase | Tool | Activity | Owner |
|---|---|---|---|
| Strategic Definition | Goals (Atlassian) | Definition of strategic objectives and key case studies, assigned to teams or individuals | Executive Team / Sales |
| Idea Collection | Jotform | Gathering of insights, opportunities, and requests via a structured form | Sales |
| Technical/Strategic Validation | Excel | Technical and strategic assessment in Excel to evaluate interest, required effort, and alignment with the Business Plan | Program Manager / CTO |
| Prioritization and Roadmap | Jira Product Discovery (JPD) | Feasibility analysis, organization, prioritization, and linkage of ideas to strategic goals through shared roadmaps | Program Manager / PM |
| Contract Finalization and Project Activation | Contract → SAP/Jira | Contract signing → alignment with Program Manager, PMM, and Controller → project creation in corporate systems | Program Manager / Controller / PMM |
| Operational Delivery | Jira Software | Conversion of initiatives into Epics, Story, and Tasks; operational project management and tracking in Jira | Controller / AM / PM / Demand Manager |
Document focus: Operational Delivery phase
Structure and Operational Management in Jira
| Level | Description | Creation | Planning | Assignment |
|---|---|---|---|---|
| Jira Space (ex project) | contract/Order of type: Production - R&D - Grants | Controller | — | Controller |
| Epic | Deliverable | Demand Manager | Demand Manager | Demand Manager |
| Story | Feature(s) of the deliverable | Demand Manager | Demand Manager | Demand Manager |
| Non-technical support tickets | Tasks that do not require time tracking (Documentation - Hardware / DevOps - Release) | Demand Manager | Demand Manager | Demand Manager |
| Executive Ticket | Tasks and subtasks that require precise time tracking, assigned individually (Bug - Helpdesk - Task_swhw - Development - Test - UX/UI - Analysis - User manuals) | Demand Manager / Tech Lead | Team Leader | Team Leader |
Simplified Jira IT Process Flow
1. Creation of the Space (ex Project)
Controller Orders the creation of the Jira Space (ex Project) and assigns the PM with the role of «Coordinatore del progetto Jira [Jira Project Coordinator]»
PM (Coordinator of: Contract/Order + Jira Space) Adds users to the space and assigns roles accordingly
2. Initiation of the Work Process
Demand Manager Creates (and assigns) the deliverable Epic and fills in mandatory fields provided by the PM:
- n° Pezzi Produzione richiesti [Number of production units requested (client's estimated FTE)]
- Data di scadenza [Deadline (delivery date to client)]
3. Operational Definition
Demand Manager Creates one or more Story for each functionality of the deliverable. Creates necessary Tasks and Sub-tasks subordinates to each Story, including:
- Executive tasks
- Analytical/functional tasks
When necessary, assigns Tasks and Sub-tasks to Team Leaders for further estimation and planning
4. Assignment and Planning
Team Leader Assigns executive Sub-tasks to users. During progress (per task status), verifies and fills mandatory data fields:
- Stima originale [Original estimate (actual FTE estimate)]
- Start Date [Gantt] (planning)
- End Date [Gantt] (planning)
Demand Manager Redefines, if needed, the planning and estimates of Story and Epic. Fills mandatory fields:
- Start Date [Gantt] (planning)
- End Date [Gantt] (planning)
* Possibility to validate data directly from the Gantt chart
5. Execution and Monitoring
Ticket Assignees
- MUST ALWAYS update the status of all assigned tickets, regardless of type (Sub-task, Task, Story, Epic). Each ticket must be closed upon completion.
- For executive tickets, correct status updates are critical for accurate time reporting via Clockwork.
- Even for NPH (non-productive hours) activities directly related to the specific project (with declarative hours), daily ticket creation is mandatory.
Reporter The reporter of each ticket is responsible for the correct progress and accuracy of entered data.
Simplified Jira IT Process Flow: Main Focus Steps in the Gantt Chart
2. Initiation of the Work Process + 3. Operational Definition
Demand Manager = Creates one or more Stories for each feature of the deliverable. Creates the necessary Tasks and Sub-tasks for the Story (both execution and analytical-functional types). Where necessary, assigns Tasks and Sub-tasks to Team Leaders for subsequent estimation and planning. Then creates the project Gantt chart. (at this stage, it will be devoid of any scheduling data as shown in the example picture).
4. Assignment and Planning
Team Leader = Assigns the execution Sub-tasks to users; during progress (second state) fills in/verifies the input of data for scheduling
Demand M. = Redefines the schedule if necessary, then fills in the mandatory fields of Story and Epic, validating the data displayed in the Gantt chart using the command shown in the picture
Mandatory Fields Completion Table
| Jira Field Name | Description | EPIC | Story | Execution Tickets | Non-technical support tickets | |
|---|---|---|---|---|---|---|
| «Pianificazione cliente» [Customer Planning] | n° Pezzi Produzione richiesti | Number of units requested for production. Estimated FTE communicated to the customer (production target defined for the ticket) | Mandatory | Not applicable | Not applicable | Not applicable |
| «Pianificazione cliente» [Customer Planning] | Due Date | Customer Delivery date (deadline set for the Epic) | Mandatory | Not applicable | Not applicable | Not applicable |
| «Pianificazione interna» [Internal Planning] | Original Estimate | Estimated FTE planned internally (internal productivity target set for the ticket) | Automatic – sum of child tickets | Automatic – sum of child tickets | Mandatory at 2nd status transition | Not required |
| «Pianificazione interna» [Internal Planning] | Start Date [Gantt] | Planned start date for the activity, as scheduled in the Gantt chart | Mandatory at 3rd status transition (can be validated directly from Gantt – see previous slide) | Mandatory at 2nd status transition (can be validated directly from Gantt – see previous slide) | Mandatory at 2nd status transition | Not required |
| «Pianificazione interna» [Internal Planning] | End Date [Gantt] | Planned end date for the activity, as scheduled in the Gantt chart | Mandatory at 3rd status transition (can be validated directly from Gantt – see previous slide) | Mandatory at 2nd status transition (can be validated directly from Gantt – see previous slide) | Mandatory at 2nd status transition | Not required |
| Start Date | Actual start date of the ticket activity | Automatic upon entering an "active" status category | Automatic upon entering an "active" status category | Automatic upon entering an "active" status category | Automatic upon entering an "active" status category | |
| End Date | Actual end date of the ticket activity | Automatic upon entering a "done/closed" status category | Automatic upon entering a "done/closed" status category | Automatic upon entering a "done/closed" status category | Automatic upon entering a "done/closed" status category |
Ticket Classification
| Type | Level | Description | Parent Container | Time Tracking |
|---|---|---|---|---|
| Epic | Epic | Main container of the workflow. Represents structured deliverables or non-project activities (e.g., onboarding, minor support tasks). | Jira Space (ex Project) | — |
| Story | Task | Short description of a feature. Explains how a specific task delivers value to the user/client. Typical format: "As a [user], I want [action], so that [benefit]." | Epic | — |
| Documentation | Task | Container for documentation-related tasks not linked to a single Story. Includes specific subtasks. | Epic | — |
| Hardware / DevOps | Task | System-related activities: scripts, configurations, environments, access management, etc | Epic or none | — |
| Release | Task | Planned release activities (to be included in GANTT planning). | Epic or none | — |
| Bug | Task | Support or operational request handling (individually assigned) | Epic or none | automatic Clockwork |
| Helpdesk | Task | Support or operational requests (individually assigned) | Epic or none | automatic Clockwork |
| Task_swhw | Task | Operational, non-functional activities not falling under standard categories (e.g., user account setup, data sanitization) (individually assigned) | Epic or none | automatic Clockwork |
| Analysis | Sub-task | Requirements gathering, estimations, High-Level Design, documentation drafting – individually assigned | Story, Documentation | automatic Clockwork |
| UX/UI | Sub-task | User Interface design/review – individually assigned | Story, Documentation | automatic Clockwork |
| Development | Sub-task | Technical implementation and development. Includes post-test bug fixing – individually assigned | Story | automatic Clockwork |
| Test | Sub-task | Development testing and validation. If unsuccessful, reopens the development sub-task or creates a new one – individually assigned | Story | automatic Clockwork |
| User manuals | Sub-task | Technical or end-user documentation creation – individually assigned | Story, Documentation | automatic Clockwork |
| NPH_swhw | Task | Container for non-productive activities (e.g., training, meetings, tech/code reviews, etc.) | Epic, specific NPH Epic | — |
| NPH_Sub-task | Sub-task | Daily log of specific non-productive hours (NPH) – individually assigned | NPH_swhw | Manual entry |
Workflow Ticket
Epic
Workflow states (in order): START → ESTIMATE ← ANY → ANALYSIS → DEVELOPMENT ← (TEST not passed loop) → TEST → UAT → RELEASE → COMPLETED | RESOLVED ← ANY
Documentation / Hardware/DevOps / Release
Workflow states (in order): START → TO DO ← ANY → IN PROGRESS → COMPLETED | RESOLVED ← ANY (PENDING ← IN PROGRESS, PENDING → TO DO)
Story
Workflow states (in order): START → ESTIMATE ← ANY → IN PROGRESS ← (PENDING loop) → RELEASE → COMPLETED | RESOLVED ← ANY
Bug
Workflow states (in order): START → TO ESTIMATE → TO DO ← ANY → IN PROGRESS → PENDING (pause) → IN REVIEW → IN INTEGRATION TEST → TO BE RELEASED TO TEST → TESTING → TO BE RELEASED TO PRODUCTION → COMPLETED | RESOLVED ← ANY
Helpdesk / Task_swhw
Workflow states (in order): START → TO ESTIMATE → TO DO ← ANY → IN PROGRESS → PENDING (pause) → COMPLETED | RESOLVED ← ANY
Development
Workflow states (in order): START → TO ESTIMATE → TO DO ← ANY → IN PROGRESS → PENDING (pause) → IN REVIEW → IN INTEGRATION TEST → TO BE RELEASED TO TEST → TESTING → TO BE RELEASED TO PRODUCTION → COMPLETED | RESOLVED ← ANY
Analysis
Workflow states (in order): START → TO ESTIMATE ← ANY → ESTIMATED → TO DO ← ANY → IN PROGRESS → PENDING (pause) → IN REVIEW → IN APPROVAL → COMPLETED | RESOLVED ← ANY
User manuals / Test
Workflow states (in order): START → TO ESTIMATE → TO DO ← ANY → IN PROGRESS → PENDING (pause) → RESOLVED ← ANY | COMPLETED
UX/UI
Workflow states (in order): START → TO ESTIMATE → TO DO ← ANY → IN PROGRESS → PENDING (pause) → IN REVIEW → COMPLETED | RESOLVED ← ANY
Time Tracking
The sub-task represents the daily activity carried out by the user for a specific task, for which automatic work hour tracking must be enabled via the Clockwork plugin – automatically activated/deactivated based on the ticket status.
When creating the item, it is mandatory to enter an original time estimate for the completion of the activity. Each day, the remaining estimate will automatically update based on the work logs recorded by the user within the item. This update occurs automatically as soon as the user moves the sub-task to the active state "IN PROGRESS" and will pause every time the sub-task is moved to a non-active state.
In the case of NPH and NPH_sub-task ticket creation (dedicated to non-productive activities that can still be linked to the project — e.g., client meetings on specific topics), time tracking will not occur automatically, but must be done manually by filling out a dedicated field.
Note: Only one ticket with automatic time tracking can be active at any given time. When a new ticket is moved to "IN PROGRESS", the currently active one is automatically moved to "PENDING". This logic does not apply to tickets where the use of automatic tracking with Clockwork is not required (e.g., Epics, Tasks, NPH, etc.).
Time tracking state logic:
- Creation → NON-ACTIVE STATES
- Work start → ACTIVE STATE (START timer) ← work resumed
- Work paused → NON-ACTIVE STATE (STOP timer, PENDING)
- Work completed → FINAL STATE (STOP timer)