Best practice: commenting Jira tickets

I will start with my normal saying when the words "best practice" come up.   There is no such thing as a best practice, just a whole lot of good ideas.  

So if your team feels like this is a good idea that they would like to follow, do it.  But if they feel like this is a good idea for some other teams, then why do they need to do such?  If a team is communicating well and their Daily Scrum is effective, I do not really see a need for something like this. 

I see a lot of value in team agreements. These might be to comment tickets in a certain way, or under certain circumstances.

For example, the developers I work with have an explicit Kanban workflow, and they comment Jira tickets when something unusual happens to affect the flow of that ticket. e.g. progress is impeded because of a change of priorities, or a new dependency emerges.

This can be useful to the Development Team because they review these comments when reviewing items with a long cycle time, as part of their continuous improvement effort. The comments help them understand what is happening, how frequently, and what observable impact it is having.

Thanks! I need to add that is not team decision. It's the decision of the new manager for is pushing the scrum masters to control those comments every day. Because it's a good "agile practice".

It's the decision of the new manager for is pushing the scrum masters to control those comments every day. Because it's a good "agile practice".

Do you think it's good agile practice when a manager pushes Scrum Masters to exert control? I'd suggest that Jira commenting is not the principal concern here.

Is the managers wish the result of an Inspect&Adapt cycle?

hi there,

My two cents.

What problem does commenting the work done by developers solve, or what purpose would it serve? When teams ask me if they need to write down everything in a ticket, I ask them "Why would you find that valuable?" The answers are along the lines of:

1. "Because that is more transparent"

More transparent than what? More transparent than looking in the code when we need to know details? Administering every ticket in a tool might lead to less transparency because we create an additional source of information that needs to be kept up to date (in accordance with the latest change and status).

Consider using the Daily Scrum for this and open communication (talking) during the day at work. Note that you are allowed to halve multiple Daily Scrums if there is a need for fast and multiple smaller feedback loops in the team. Direct communication is far more effective and administration is not a goal in itself, creating value for the customer is.

If you choose to administer anything, administering exceptions is useful, for instance when a ticket is blocked give some info why and by what/whom. All of this in case you forget or to enable a teammate wants to continue working on the ticket with the least amount of hassle (customer-centric thinking, where the customer is your teammate).

2. "In order to ensure we can trace back who did what if we get an audit"

If there are regulations to adminster all these details, then you don't have a choice. However, in general, a customer does not pay for well-documented tickets, but for working software. So if you can avoid administration overkill than do so. If the request to adminster such details comes from management, you might want to discuss this desire to understand why this is important to mangement: What do they do with this information? What problem does it solve? Is it cost-effective to do this?

3. "Because this increases productivity."

I never heard this argument. In what way could this be true? I doubt if this is true if we adminster every detail. Adminstration work takes time and effort. It is unclear to me how any productivity gain can be expected by documenting every ticket every day. I suggest commiting code to master every day is more likely to create a productivity gain.

hope it helps

roland