In any software project, maintaining a clear ticket hierarchy is essential for organizing work, ensuring accountability, and driving efficient development. In this post, I’ll break down the different ticket types used in JIRA and how I structure them for my Permabot project.

Understanding JIRA Ticket Types

JIRA provides several ticket types, each serving a specific purpose. Here’s how I categorize them:

• Epic – A high-level deliverable representing a scoped user value.
• Story (User Story) – A feature or user interaction that enhances the product.
• Bug – An unintended behavior that needs fixing.
• Task – Non-development work, such as data backfilling or customer interactions.
• Subtask – The smallest unit of work, breaking down a Story, Bug, or Task.

A well-structured hierarchy ensures clarity in ownership, progress tracking, and smooth execution.

Example: Permabot’s Ticket Hierarchy

Here’s how I structure JIRA tickets for Permabot:

1. Epic: Clearly defines end-user value and deliverables.
2. Stories: Break down the epic into actionable work.
3. Bugs: Track issues that arise during testing.

JIRA Ticket Breakdown Example

For Permabot v2.3.1, the Epic started with these high-level goals:

• Improve logging to capture delta values for option legs, enabling better risk assessment and strategy adjustments.
• Implement dynamic contract sizing to limit potential losses to a maximum of 3% per trade on a $21,000 account.
• Enhance logging for HTTP errors to improve debugging and system reliability.

Here’s how my JIRA hierarchy appears in the timeline view:

During development, the number of features expanded due to scope creep. While this is natural, as deeper exploration surfaces additional issues and opportunities, it’s crucial for a product manager to monitor and manage scope effectively. As a general rule, I allow developers to add necessary stories when changes to existing code are required to deliver on the original goals. For instance, before enhancing HTTP error logging, it may be necessary to implement basic logging first. However, external stakeholders should not bypass the product manager when requesting additional features directly from developers.

Another key takeaway is that the Epic initially had zero bugs, but as development progressed, unexpected behaviors surfaced—especially given that the software is still evolving despite being at version v2.3+. This is normal. Logging these issues ensures they are addressed appropriately, whether as immediate fixes (P0 priority) or for future consideration (P1+ priority). I’ll cover prioritization strategies in a separate post.

Example Changelog: Permabot v2.3.1

Here’s a real changelog from one of Permabot’s releases:

## [2.3.1] - 2024-XX
### Added
- Configured max delta to 0.20 and stop loss is 1.75x
- Created Utils function to log response / requests for debugging
- Dynamic sizing defaulting to 3% max loss on 21000 act
- Added push notifications for active monitoring, alerting in event of 401
- WBPR Bot: Refactored William's Brown Price Reversion strategy supporting >1 daily entries
- Introduction of Perma Journal
- WBPR Bot: standardized notifications
- Json dump utils with logger support

### Fixed
- monitor_and_exit loop continues forever when there are http errors, in case connection comes back.
- WBPR Bot: no trade days end the bot

Final Thoughts

A well-defined ticket hierarchy in JIRA helps ensure a structured and scalable software development process. By clearly defining Epics, Stories, Bugs, and Tasks, teams can streamline execution and maintain better control over project progress.

How do you structure your JIRA tickets? Let’s connect and share insights!

Throughout my career, I’ve had the opportunity to build and scale small software development teams. As a technical product manager, I rely on time-tested processes to ensure smooth software iteration. One of the key aspects of scaling a team is defining a clear product development lifecycle. Today, I’ll share my approach to structuring this lifecycle, ensuring that software iterations flow as seamlessly as possible.

Understanding the Development Lifecycle

At its core, the product development lifecycle follows the Build → Measure → Learn loop. This iterative process ensures that the product evolves continuously:

1. It starts with an idea (feature request) or a bug (unintended behavior or learning).
2. The team moves into development.
3. The feature undergoes quality control:
   • Automated testing (unit & integration tests).
   • User testing (where applicable).
4. The feature is deployed.
5. Bugs or new learnings emerge, restarting the cycle.

A well-defined lifecycle helps teams minimize bottlenecks and improve efficiency.

Example: Permabot’s Development Lifecycle

To illustrate this process, let’s look at how I apply these principles to my Permabot project:

1. Feature Ideation – Every new idea starts as an Epic in JIRA, providing a high-level view of the initiative.
2. Bug Tracking (Ongoing) – Issues discovered during development or testing are logged as Bugs, which are prioritized for an upcoming release.
3. Development Phase – Code is written, reviewed, and prepared for testing.
4. Testing & Validation – Both automated and manual testing ensure that new features and bug fixes meet stability and performance expectations.
5. Deployment – The validated update is released into production.
6. Iteration & Continuous Improvement – Bugs and feature enhancements from the latest deployment are logged, feeding into the next development cycle.

JIRA Workflow Example

Here’s a look at how my JIRA workflow is structured:

Being a team of one allows me to keep my workflow simple, yet structured enough to ensure quick iterations while maintaining software stability. One key aspect I’ve found useful is having a “Won’t Do” state. Plans change, and keeping an audit trail of ideas—along with the reasoning for cancellation—prevents unnecessary churn when those ideas resurface in the future.

Additionally, you’ll notice that all statuses can transition freely within the workflow. This flexibility allows tasks to move as needed, avoiding unnecessary process constraints. While some teams may prefer a strict, linear workflow with clear handoffs and deliverables between states, I’ve found that overly rigid workflows often make JIRA a blocker rather than an enabler for agile development. Ultimately, the tool should adapt to the team, not the other way around.

Final Thoughts

Defining a clear product development lifecycle ensures that software teams can scale efficiently and iteratively. JIRA workflows play a crucial role in enforcing these processes while keeping development streamlined.

How do you structure your development lifecycle? Feel free to reach out—I’d love to hear your thoughts!