Should I create tickets in an early stage of a software?

[Robert Schneider]

In our team we have a not so sophisticated process regarding the development of new software or new features in existing software. I could imagine others are doing it similar: Develop something and then see if it works. If not, the software has to be further adopted/developed.

We use versions of course, but in that stage we don't want to care about versioning. At least the team regard this as cumbersome and wants to avoid it, until a final stage gets reached. Personally, I could imagine to do it more formal, but I can also imagine that it turns out to be an unnecessary overhead.

My question now: Should I create tickets or should I just list issues someplace (checklist) in order to organize tasks? If I try out the developed software/feature and I recognize bugs or problems or I see that something is missing, I'd like to write it down and let the developer know, what needs to be done. I'd like to use tickets for that reason, so that it can be worked through by the team and I can watch the progress (using ticket status).

I'm just wondering about how to deal with these tickets. Using no affected/fixed version? Deleting all when development has finished? Would you say, using tickets is always a good idea? Or would you advice against it, to keep it simple?

How do you deal with it? What are your experiences?

[Rilwan Ahmed]

Hi @Robert Schneider ,

Welcome to the community !!

Regarding your below question 

"My question now: Should I create tickets or should I just list issues someplace (checklist) in order to organize tasks? If I try out the developed software/feature and I recognize bugs or problems or I see that something is missing, I'd like to write it down and let the developer know, what needs to be done. I'd like to use tickets for that reason, so that it can be worked through by the team and I can watch the progress (using ticket status)."

--> I suggest create ticket and whenever you find the bug, add comment in the ticket, change status of the ticket and assign back to dev team. If there are multiple bugs, create subtasks and assign to dev team for the fix.
When dev team fixes, they can assign back to you for testing.

[Robert Schneider]

Thanks for the reply. I think, I will do it like this.

But I'm still wondering about versioning in this stage. I know how to deal with it, when there is a clear roadmap or when there are bugfixes for an already released software. In that case there is an obvious affected and fixed version. But if there is no release yet and we don't want to deal with declaring versions like 0.1.0, 0.2.0, ... for every little change, to what should I set the affected/fixed version? There is no real process in this stage and actually I understand that people don't want to fiddle with versioning.

My concern is, that if I do not have a rule for ticket versions in that stage, the Jira project may be cluttered. So I thought it might be an approach to delete such tickets when the software was released. Or change the version of the tickets to the final one?

Obviously, there is some confusion in my head.

[Nikola Perisic]

Welcome to the community @Robert Schneider 

In my experience, we have indeed used Jira for specific reasons of project tracking. This indeed included the both development tasks and bugs. Both were documented and we knew what was going on in the project. Who was the assignee, what was the status of the issue. If it was for too long in the same status, I would ask for the feedback.

The goal is always to have the working software which is also part of the Agile manifesto, that of course you don't really have to follow. It creates a more sense of having everything structured in one place. I would say to go with creating the tickets. When it comes to organizing I would recommend going with Scrum since it is based on estimation, organization of tickets for the sprints and finishing the work in small increments that take 1, 2 or 4 weeks long (sprints).

[Robert Schneider]

Thank you for that. I like Scrum, but I have also experienced that it has some overhead in a small team. We are not so organized yet too, unfortunately. I cannot introduce Scrum right now.

[Nikola Perisic]

You can then go with team-managed Kanban board. It is meant for smaller teams, easy configurations, and no need to have Jira admin to configure the schemes.

[Valerie Knapp]

Hi @Robert Schneider , welcome to the Atlassian Community and thanks for your question.

If you want to make a list of tasks while you are still qualifying for example what a software release should do, you can of course create some issues in a Jira project and then, even using automation, transfer the issues into a software development project when they are ready to be worked on by another team.

I think there are many possibilities here but I will mention two.

One is that you could create a Jira Business project. These have a much more user-friendly kind of look and feel and functionality -

Here you can see we have a bunch of different tabs but the one I am highlighting is where you can just make a list of things and populate the field attributes you want. There is the board, if you want to move them across a workflow, but you can also just keep track of the ideas in the list.

The other possibility would be to use Jira Product Discovery. This is another Jira product where you can, again, make a list of ideas with the goal of qualifying them for further development in a software or other project.

You can see that this is still recognisably a Jira product, but this product is really for refining ideas and measuring the strength of them before you start developing.

Let me know what you think.

Cheers

[Robert Schneider]

Thanks for the input. Product discovery looks interesting, actually. But it would be already too "professional" for us, since we have smaller projects.