If the time reporting requirements are imposed externally (e.g. through contractual client requirements), then you need to communicate those reasons effectively to your team. If they are imposed internally by your own organization, then you need to examine your process carefully before deciding on your approach.
Determine Value for the Process
However, [the developers] are not happy to complete their time sheets. How can we convince them that both are important? Or should we stop using time-sheets?
On some projects, and in some organizations, labor costing needs to be calculated. This almost never has direct value to the people performing the actual work, though---it's a tracking metric for budgeting purposes or for management reporting.
This doesn't seem like it's the case for your project, though. The very fact that you ask if you should stop using time-sheets indicates that it is an optional metric. What exactly is the point of tracking something no one wants to report, and no one cares about if it isn't reported? That's called make-work!
Other Ways to Report Hours
If all your staff are on salary, then the time-sheets are irrelevant. All you really need to know is whether stuff is getting done, not whether Fred charged 7.25 hours to Project X and 12.5 hours to Project Y---unless your organization forces you to track that way.
Perhaps you can simply say something like:
- We had X people working full time on the features delivered this iteration.
- This milestone took the efforts of the entire team over the past 30 days.
The trade-off is that you can calculate labor costs at a macro level in seconds, but you can't get at the granular details. Perhaps this is sufficient for your purposes.
Alternatively, if all your people are hourly contractors, they need to give you an invoice or statement of hours anyway. Why not just use that, instead of requiring additional book-keeping? Again, the trade-off is simplicity vs. granularity.
Unless you're doing complex accounting for matrixed teams who are simultaneously charging against multiple projects, why make the time reporting any more complicated than it needs to be? Just track your labor burn-rate against your project's budget and call it good.
Possible X/Y Problem
While a project manager with budget-tracking responsibility needs to track labor rates on a project, how you track it and the level of detail you track depend on what you're solving for. Before doing anything else, you need to figure out why you need this information, and how you plan to use it.
It has been my personal experience that this level of granularity is often used as a proxy (or worse, as a stand-in) for measuring productivity on a project. More hours charged to a project doesn't equate to faster delivery, nor do fewer hours intrinsically equate to process efficiencies.
For example, a spike in hours might be a project smell indicating hidden process problems, increased complexity, or a higher defect rate. Then again, maybe not. As a metric, tracking hours only directly correlates to money spent on labor; by itself, it tells you nothing about the status of a project's deliverables.
Think carefully about why you want or need to track hours the way you do. If you can't come up with a good reason for it other than "just because," neither can your development team.