Pretty cool! Congratulations on launching a useful product.
As a side conversation, this project and how you described it made me think about why I have such issues with Jira. Jira is actually fucking useless to me. To the business, it's indispensible because it captures the larger tasks that roll up to a larger business objective. However, for each of those larger tasks I have a series of conversations and cross-functional dependencies that must be negotiated. More basically, my minutiae is much more than the larger tasks can ever describe, and that minutiae is much too noisy for the business to track - which is why we cover it informally in stand ups.
What I need is something offline that tracks my minutiae like stories where the larger tasks (that are currently stories to the business) get tracked like epics on my end.
I say this from the perspective of working at a very large, top-level engineering firm.
Similar take re: Jira at work. But for me personally, Jira is valuable in that it at least provides shorthand for a body of work. I manage my own deliverables (and my small team's, to a lesser extent) in Obsidian, in a work-dedicated private vault. Referencing Jira tickets ("WF-1234" or "CICD-9999") in my per-project devnotes is helpful for organization and providing centers of gravity for related | interdependent notes. YMMV but it's been working fairly well for me.
This is a huge ask, but would you mind elaborating on your workflow a bit? I really struggled with Jira at work, and I _think_ it was for similar reasons that you described.
Are you saying that what is a story at work, and captured within a single “unit” within Jira (I don’t want to use “task”, because that’s a separate thing in Jira) is more broad, but you benefit from having that story broken down further, and that’s where you would use something like Upbase?
Yes. Most organizations I've worked in have an OKR, several epics from that OKR, and several stories from each epic. I tend to work on stories all across those epics, but even broken down stories can never be broken down enough for a single programmer. They're still broad because I'll need to gather requirements from external teams, get a permission here, or dive into a deployment workflow there in order to fully close the story. To the business, a story is the smallest unit of work, but to a human we have many steps in that unit of work.
In a contrived example, if my OKR is to reduce the engineer attention in a given support process by 50%, my epic might be to create a framework for automating tasks via Slack. My stories then might be:
- Spike: Investigate Slack API
- Spike: Investigate programattic interfaces of Jenkins
- Build bot framework
- Build pluggable Jenkins module
- Spike: determine deployment patterns for framework + modules
To a business, these are bite-size as the chunks can be, but to me that may involve tracking threads in channels, doing POCs, and doing a lot of reading. All of those things may fall under a single story.
In a laymen's sense, I need a Jira for my Jiras that the business doesn't need to track because those things largely don't matter to the whole.
For me I think it depends on how your org is handling the source of truth for tasks and work. I know you can use checklists within stories and tasks to break things down without cluttering boards with new tickets, and capturing discussions within the ticket itself helps to compartmentalize things and avoid jumping around different tools.
If a story is your smallest unit of work, does one developer own a story? Or are multiple people working on it? Intuitively it feels like if multiple people are working on a single story then it feels like that should (or at least could) be broken down into subtasks (or checklist items, if you didn’t want to create new tickets) that could be split between developers, and keeping that context and discussion within that ticket, I would think, would be helpful for knowledge sharing and drawing from that discussion to feed into your longer term knowledge base docs.
Just food for thought from someone who tool hops way too frequently with poor short term memory .
There is an optimal amount of work breakdown before starting the work. It sounds like you wish there was slightly more detail and some type of infinitely nesting tasks.
Sometimes it's not worth putting everything into a ticketing system.
As a side conversation, this project and how you described it made me think about why I have such issues with Jira. Jira is actually fucking useless to me. To the business, it's indispensible because it captures the larger tasks that roll up to a larger business objective. However, for each of those larger tasks I have a series of conversations and cross-functional dependencies that must be negotiated. More basically, my minutiae is much more than the larger tasks can ever describe, and that minutiae is much too noisy for the business to track - which is why we cover it informally in stand ups.
What I need is something offline that tracks my minutiae like stories where the larger tasks (that are currently stories to the business) get tracked like epics on my end.
I say this from the perspective of working at a very large, top-level engineering firm.