3 ms·

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

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?

kodah 4y ago
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.
- jonwest 4y ago
  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 .
- beckingz 4y ago
  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.

kodah 4y ago

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.

jonwest 4y ago
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 .
beckingz 4y ago
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.