Problems in a working software take different forms: defects, bugs, mistakes etc. And then there are issues reported by customers. Should customer issues be part of your project’s backlog? To answer that question, here’s a scenario:
Scenario: For your software X, version 1.0 has been released. Your team starts developing the meatier features of the next version, scheduled 3 months later. As the days pass, you start receiving emails from your customer users.
One email says a requested functionality has been implemented incorrectly and the user is not at all satisfied with the result. “Would you kindly redo the functionality as it is required for day-to-day functioning?” the user writes. Another says that a newly implemented feature needs to be explained to their team. Yet another has a handy suggestion for an existing feature.
Now the catch: the term “Issue” was used for all the above three points by the customer users. But are they actually issues?
The first point (redo the functionality) is really a requirement change. The second point is a request for support. The third point is a suggestion.
Imagine adding these three points directly to your Project’s backlog, simply using the term “Issues”. Deciding what should be done with this sort of backlog, will not be easy. Which Issue should be resolved first and who should do it? In the meantime, if some more Issues are added, then your backlog will start to clutter up.
Instead of using an umbrella term like “Issues” for customer feedback, what if Issues could be categorized in more Project-friendly terms and THEN added to the Backlog?
For example, point A is categorized as “New Requirement”. Point B is “Support request” and Point C is “Suggestion”. Priorities are also assigned. A affects the customer’s user day-to-day work and hence, is “Important”. B’s priority depends on the support team’s availability and C’s priority can be “Later”. However, if it is a good suggestion and adds value to X as a product on the whole, it should be categorized as a new requirement or feature.
Since prioritization and categorization is done, team members can effectively and easily make decisions as to which Issues should be added to the Backlog. Since A is “Important”, it can even be implemented on priority and deployed as a patch (making the customer user happy).
Backlog managers are happy, since the backlog is not simply cluttered and it is easy to make out what is actual backlog added for development and what are customer issues to be included as part of development.
Deciding which Issues should be converted into Backlog items after categorization, can be performed by a single person or a group of individuals, depending on the internal workings of your organization.
If formal approvals are required before adding to a Project’s backlog, a review board should be set up to review the categorized Issues. For smaller teams, where it is possible that a Product owner manages both support and backlog, he/she can directly add to the backlog.
So, finally can the question “Should Issues be part of your backlog?” be answered?
The short answer: Yes after Issues are properly categorized and prioritized by the backlog and support team in tandem.
Ria is the system analyst for JamBuster's agile project tool - SoftAgile and agile ALM tool - SoftALM.