3 ms·

Funny how he casually mentions JIRA as a process that slows you down. I get that his team does the issue tracking somewhere else? What does people use that is

by Anduia 2y ago

Funny how he casually mentions JIRA as a process that slows you down. I get that his team does the issue tracking somewhere else? What does people use that is faster to process both for devs and the PM?

skydhash 2y ago
It always depends on the team. And by team, I mean the people working on a somewhat independent part of the project (they don’t need to care about the minutia of some other parts). Issue tracking is a tool, but project managers always wants the tool to become the process. And that’s when you got daily standups, story points, epics, and fixed sprints (aka fake deadlines). Use the tool as a tool. As the devs, add issue and tasks that needs the attention of the team, comments on a ticket for knowledge retention. As the manager, schedule the ticket if its completion matters in a particular timeframe, use assignments and other fields to manage workload. Do all of these to help the team get things done. Anything else is a hindrance.
- Anduia 2y ago
  Correct, but JIRA is not SCRUM. Why does the author mention JIRA as a process? Does he find it slow or convoluted compared to other tools? Or does he think that using JIRA means a PM is forcing the team to follow an unwanted process?
  - magicalhippo 2y ago
    > Or does he think that using JIRA means a PM is forcing the team to follow an unwanted process? Think that must be it. We use JIRA at work. We have very, very simple processes. We create issues, we assign them, we resolve them and they're closed when deployed ok. Minimal fuss. I also have access to a customer's JIRA. They have like 6-7 steps between starting working on an issue and saying it's deployed in test environment. Another 5-6 to say it's delivered in prod. I saw the flow chart for the steps and it made my head spin.
marcusbuffett 2y ago
That was more of a subtle joke than anything substantive. I think JIRA is probably fine as long as it’s not like a religion
- Anduia 2y ago
  I took it literally, sorry ^^ Thanks for your valuable advices!

by Anduia 2y ago

skydhash 2y ago

It always depends on the team. And by team, I mean the people working on a somewhat independent part of the project (they don’t need to care about the minutia of some other parts). Issue tracking is a tool, but project managers always wants the tool to become the process. And that’s when you got daily standups, story points, epics, and fixed sprints (aka fake deadlines). Use the tool as a tool. As the devs, add issue and tasks that needs the attention of the team, comments on a ticket for knowledge retention. As the manager, schedule the ticket if its completion matters in a particular timeframe, use assignments and other fields to manage workload. Do all of these to help the team get things done. Anything else is a hindrance.

Anduia 2y ago
Correct, but JIRA is not SCRUM. Why does the author mention JIRA as a process? Does he find it slow or convoluted compared to other tools? Or does he think that using JIRA means a PM is forcing the team to follow an unwanted process?
- magicalhippo 2y ago
  > Or does he think that using JIRA means a PM is forcing the team to follow an unwanted process? Think that must be it. We use JIRA at work. We have very, very simple processes. We create issues, we assign them, we resolve them and they're closed when deployed ok. Minimal fuss. I also have access to a customer's JIRA. They have like 6-7 steps between starting working on an issue and saying it's deployed in test environment. Another 5-6 to say it's delivered in prod. I saw the flow chart for the steps and it made my head spin.

marcusbuffett 2y ago

That was more of a subtle joke than anything substantive. I think JIRA is probably fine as long as it’s not like a religion

Anduia 2y ago
I took it literally, sorry ^^ Thanks for your valuable advices!