Using scrum and adding bugs later

Jane Scolieri

Which is the best workflow to use when creating a project where we have a small team and want to be able to use this project during and later in the bug phase? The Simplified Agile workflow looks odd and incomplete compared to the more understandable default one. Is the Jira built-in workflow the same as the Jira Default workflow?

I know I should create the project and board at the same time when starting a Jira Agile project/board but not sure what is the best workflow to use. In addition, we turned the resolution field active for editing an issue globally, because devs were unable to edit. But now it's forcing us to choose a resolution when we're just creating a new bug, which clearly no one needs to do at that point.

I did get one response from someone at Atlassian, but it doesn't help me to just say "Remove the resolution field from ALL screens except the ones that are used for transition from "open" type status to "closed" or "resolved" status", because we're still faced with the problem of when do we get to edit that field? It also doesn't help me to just say "the problem is in your workflow".

This is getting pretty frustrating because I really don't want to get too far into editing anything (workflow, etc). I'm not a programmer and we're a small company and it's just not worth the effort. I'm pretty unclear even after reading all the documentation, how status/transitions/resolutions and workflow all fit together.

Do you have a simple step by step process I can use to get the ball rolling? (Not Jira Agile 101, I'm not finding the documentation that clear)

Can you recommend a video that will explain all this in a fairly simple fashion?

Thanks!

Ivar

I'm not sure what your question really is. A video showing how to work with workflows? 

What is your intention with Jira? What are you going to use it for?

"Turned on the resolution field active for editing an issue globally, because devs were unable to edit" What? 

"I'm not a programmer and we're a small company and it's just not worth the effort"

If you have developers, they hopefully have a process they are following during development. If not, start using the JIRA default workflow out of the box. It is a very simple and straight-forward workflow. 

If they have a process, and need to adjust the workflow to support it - adjust the JIRA standard workflow, or create a new one from scratch. If this is the case, I suggest you create a test project, test workflows, tests screens and start to play around with it. We have a project called PLAYGROUND, where we try out new stuff "in production" and see how they work. Once we know how to achieve what we want, we copy/config the changes to the "live" development workflow. 

I can agree that the setup can be a bit overwhelming - screens with screen schemes, issue types with issue type schemes, transitions, statuses, which screen to show when with what fields, etc. But in the end, you have started to use a system that is highly adaptable - and you will have to pay the cost of getting to know the system before things start getting easier. 

One alternative is also to "give" it to the developers.