At some point our project manager (PM) switched to a Kanban-like board (we have "Open", "In progress", "Verification", "Feedback", "Analysis" and "Test" fields on the board; our project follows (I think) the V-model that is we do a lot of testing along with the implementation of features and bug fixing). Since I joined the team after this was introduced it's all I know from this project.
As time went by I found it more and more problematic to work with the way things are because:
- the client has their own ticket repository (Polarion from Siemens; no matter how many "awesome" features it offers it is, in my opinion, an incredibly broken/incomplete pile of junk)
- we have our own Redmine (digital tickets :)) and
- board with tickets on paper
The way things currently work are:
- Client finds an issue and creates a ticket in Polarion
- Our PM (or someone from the dev team) looks through the opened tickets
If a ticket suitable for us is found (that is, its category is Software), the following needs to be done:
- Create Redmine ticket
- Create paper ticket and hang it up on the board in "Open"
In addition we have two members of our team who work remotely which means that they have to "bother" someone to create the paper version of the ticket and manage it on the board in their stead. Our PM tries to do it but it's not working so well to be honest.
To add more to this we also have internal tickets that represent problems that our client hasn't found yet (might never do) that we keep away from Polarion since the client has no access to our Redmine. Posting a ticket number to a ticket that is not visible for the other party doesn't make much sense.
All this was bothering me at the very beginning (I like taking notes on paper but not managing that paper) but it became worse when we had a couple of big waves of tickets shipped from Polarion most of which weren't reproducible (hence had to be hung up in the "Feedback" category on the board and in Redmine). The more tickets we had on the board the more difficult it became to find anything. Me and my colleagues sometimes spend several minutes to find the given ticket (my personal record is approx. 10 minutes), which is not only a waste of time but as you probably imagine incredibly frustrating. If you are unlucky enough the ticket might not actually be present on paper because someone forgot to do it/was not able to (like the two colleagues who work remotely).
This stacking up of tickets with status "Feedback" led to the creation of a new process - we now have a separate from the board pile of tickets on paper that are not reproducible and require a different type of feedback (the normal "Feedback" in our project is when we require more information on the specification) - Dear client, please don't post a screenshot and say it doesn't work as expected while at the same time the screenshot is not even of our own software but of a third party tool that you use for the simulation of the system (and we don't have) or "Dear client, please read your own specification..." etc.
And of course we always have to work with the paper tickets too. I always create Redmine tickets when I find a bug, document everything and basically take care of the digital side of the ticket system. However sometimes I forget to create a paper version (it's not just me, happens to many others too) which annoys the hell out of the PM.
I'm interested in the general practice out there (I don't have much experience to be honest) when it comes to ticket management on paper. Is it suitable for big projects at all (we are 11 people and work for more than 2 years on this project; tickets on papers is something we have for a couple of months now)? When is it time to say enough with the paper and move to digital-only medium?