Should I word backlog items as what's broken or what work needs to be done?

Question

We have a software project that we are trying to implement some basic project management for and we're starting simple, just using a Trello kanban board to track bugs/feature requests. I am beginning to transfer items from our in-house help desk system (which doesn't have any tracking features, it's basically just a record of user-submitted tickets with some searching and email built in) into a Trello board called "<insert product name here> Backlog". In this board, we have Bug and Feature filters, as well as additional filters indicating what section of the app it relates to.

I'm conflicted on whether items should be worded as what is broken or as what work needs to be done. For example, if I have a help desk ticket that says "Financials on this page have a rounding error", do I create a card with that wording, or should I call it "Fix rounding error on x page"? Or, as a third option, do I word it as what "should be"? I.e. "Page should have no rounding errors". Perhaps this is an X/Y problem and I'm trying to do too much with this board, but I don't know.

I am a developer turned accidental project manager with no prior PM experience, so any and all advice is appreciated. Not looking to become a scrum master here — I quite like software engineering — I just want to learn and implement some best practices.

Answer 1

Bottomline: go for the approach that'll help you solve the end user needs (features or bugfixes) faster.

A task should reflect the issue from end users view. You can do a triage, but I'd avoid rephrasing what the user has complained about.

There are three main reasons to stick to user wording:

1. it's a waste of time to rewrite what's already written
2. maybe the team can propose the correct solution for the wrong problem due to a poor understanding
3. maybe the solution provided is correct and the end user reported it wrongly, and you'll want some sort of minimal evidences to substantiate it

With that in mind, it doesn't mean that you shouldn't improve the wording. You just should do this with them, together. Assuming you have a constant set of users, the best approach is to have a frequent communication with users and explaining how they could provide better and clear information for quicker solutions. "Help me help you" mindset.

Answer 2

The language you use on backlog items should reflect the intended audience.

If you anticipate non-team members getting value from the Kanban board then it makes sense to use the language of end users (what's broken).

If you think the main users of the Kanban board are the technical team then it makes sense to use technical language (what work needs to be done).

It is also possible to combine both. For example, you could have a top-level backlog item written in the language of end users and then have sub-tasks that are more geared towards the team.

I would recommend you identify the main users of the Kanban board and then adopt an approach. Try it for a while and then inspect the results. Did it achieve what you had hoped for?