Or a bug, because naming everything an issue can (and will) be misleading and you may end up in court! Because the Oxford English Dictionary says:
noun
– topic of discussion
– problem/worry
Such an ambiguous word can lead to expensive misunderstandings. Inexperienced customers, managers and bosses tend to want everything for tomorrow. Project management and prioritizing is hard, estimating is even harder, especially when your work is “just writing some code”.
Expensive example
One of my costly misunderstandings involved everchanging requirements, super tight deadlines, a platform with terrible support and a customer with millions of ideas. Ideal combination for a dissatisfied business partner and grudge for life. Let’s see the recipe!
The owners of this startup were mechanical engineers and they already had some terrible experience with electronics + software. I was the 4th contractor, but the codebase never heard about versioning, half of the functions were just obsolete and unused (“Yeah, those parts? Nah, we dumped that hardware years ago but kept the source.”) and could easily win an official spaghetti code award. Maintenance and adding new functionalities was practically impossible, it cried for euthanasia.
Since the mark 2 of their product was planned to come out in 3 months, we decided on changing almost everything: we only kept one custom PCB and some mechanical parts, changed everything else for a newer and/or bigger version. Complete SW rewrite in 2–3 months, with introducing some agile methods, since the basic functionality can be easily coded in 2 months, and the wild ideas can be refined and added later on.
Don’t just introduce people to agile
Of course, some of the parts went out of stock during development, new requirements and other (mostly understandable) changes were added for the first release, some impossible bugs came up (like the very same binary works on some hardware and fails on another), but the planned first release miraculously happened and all the planned features were done.
The deadlines were met, the product’s first version was shipped as planned, but new features started popping up while the payment was not coming. Something was fishy.
People who are unfamiliar with agile methods tend to misuse it. I think the biggest strength of agile development is having a (somewhat) working product early and add requested features later. Having a product idea with millions of features is great, but while you are polishing The Perfect One, your competitors came out with the 3rd iteration of their product, making a lots of profit. Does a washing machine REALLY need an animated remote web interface and a mobile app? Maybe, but sell some “regular” ones before launching the smart one.
So, sit together, discuss even the wild features, draw a roadmap, and make it clear:
One release means a fully functional product. It can be sold, has all the stuff you aggreed for that period, time to pay.
Meaning matters
My customer misunderstood 2 concepts: release and bug. As days passed and I started to work on a new release, they continued to flood me with new, urgent ideas. We (finally) had an online board where they listed the bugs. Yes, there were truly unexpected results, valid bugs. But one thing started to annoy me: they started adding new feature requests as bugs, over and over again!
I told them countless times that the bullet points in the “future ideas and features to refine” section are not missing things, but tasks for later releases. After fixing all the high prio bugs and adding all the planned features for the next release, I finally realized: they expect all these features for free, as maintenance!
They not only postponed all the meetings about payment. When I told them that I refuse to work furhter without payment, they completely went silent. I lost my patience after 3 months, billed them (just) the first 3 month’s work. Finally, my phone rang. Long story short:
They claimed that I still haven’t finished the job and they are still working on my issues.
Were they correct? If we use the word “issue”, yes, they were technically. Got some “Well, meet at the court, we have some experience with this!” and “Expect to pay reparations!” threats (so they already did this a couple of times, great) as a bonus, but let’s focus on words.
Proper names
Issue. Yes, TECHNICALLY we can categorize everything as an issue during development. The product is not 101% ready, and it’s not making billions in profit. That’s really an issue! But different words were invented to be expressive as possible. Let’s see, how could we categorize things in a backlog.
Item. Also problematic, since it’s too general, but a much better colllective name, without the negative overtone.
Bug. When the word “error” manifests. If you want to say “something is not working but in a broken way”, bug is the perfect word for you. Something is implemented, claimed to be in working condition, but differs from specification: it’s a bug! Not implemented, but planned to implement: NOT A BUG!
Task, user story, feature request, idea, improvement. They can mean the same: “something is not doing the thing I expect, because no one made it to do so — yet”. Your methodology refines a user story to tasks? Your choice. But these should express that the product will do more, not fixing errors.
So, when people complain too much about issues during development, throw out the negative thoughts and words, focus on the positive things, because it’s a creative process!