Who should write the changelog of a task? Developer or tester? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 7 years ago.

Improve this question

I work at a software company that maintains some products.

We use a "bugtracker" to manage all tasks related to the products in question.

We work with Scrum, and the company's routine is basically the following:

1. The customer comes in contact with the support and requests to solving a problem or implementing a feature.
2. The owners of the product group the tasks in order of priority and directs them to a Sprint.
3. Developers finalize the task and ultimately are required to fill out a kind of "changelog".
4. The testers ensure that the coding of the developers was done correctly and end the call.

Here is my problem:

Developers do not like to fill the "changelog", and usually forget to do it.

Here is my question:

Who should complete the "changelog"? The developers and testers?

This "changelog" is sent to end customers at the end of each Sprint, and basically serve to explain in nontechnical what has been resolved or implemented in software.

And then, who should do it? Developers and testers?

Answer 1

This isn't a Scrum question, it reads like a process question. Can I also state that Scrum doesn't really lend itself well to maintenance work and that you may be better trying Kanban in that situation?

That said, although Scrum does not include any reference to changelog artifacts, I'd say that it's a team responsibility to ensure that the changelog is updated (as opposed to any one developer or tester). To act as a reminder, The team may want to consider adding this requirement in to their 'Definition of Done'.

Hope that helps.

Answer 2

Find out what works best for your team. It seems odd that developers/testers would be communicating with customers directly. I would expect that to be the role of the support team who was originally in contact with the customer.

As you said in your comment, they are likely dragging their feet because it's not what they are good at and thus they don't like doing it.

A couple things to try:

• Put everybody in a room and talk it out (doesn't work if there are too many people - maybe just get the dept heads). We need this to get done, it isn't getting done, why not and who has ideas how to fix this?
• I'm not sure why the customers even need a description of what was changed - I'm picturing a "how we fixed it" situation. Who cares how, just that it is fixed. I'm saying to re-examine if this is necessary - perhaps there is an easier suitable substitute.
• Try to automate it. If the customer does need a hand holding explanation of how it was fixed and all they really need to know is that it was fixed, perhaps you could automate your bug tracking tool such that the customer who reported the issue is notified when that ticket is closed - or rather, when it is deployed and visibly fixed for the customer.

Biggest piece of advice is to not make this a blame game situation. Your coworkers aren't unreasonable people - if they are resistant, then perhaps the process is too heavy. Be open to alternative solutions.

FYI - This kind of question may do better over at pm.stackexchange.com