Nothing in OPs comment says it should only be completed stuff that goes into the status.
Also, if your team is optimising for the status report, your manager has already failed you.
Also, if your team is optimising for the status report, your manager has already failed you.
With time and experience, you'll learn that those who can quickly churn out features and bug fixes are deemed extremely valuable to the company.
Let's say we have a wicked bug that has very little chance of happening. But if it does, it'll bankrupt the company, no questions asked. Spending 3 weeks fixing it is nowhere as impressive to the company as Joe who's churned out 10 features per week while your status updates are "Hunting for the wicked bug", even if you describe it it more details.
Yes, because this one task appears as a single line item for the manager's manager. They don't care for the complexity or consequences until the fire actually happens. And if the fire happens, they just blame engineers.
If the industry incentives were changed such that manager heads would roll for mass outages, managers would start appreciating big fixes.
That’s why devs who understand that survive layoffs and the ones who spend three weeks “hunting for an extinction level bug” don’t.
If you're providing a status report, you're optimizing for the status report. Period.
Engineers are not providing status reports. The manager is collating them. How is it any different to a sprint summary?
That's why these kind of incentive structures are dangerous and why things like OKRs put such heavy emphasis on regular, company wide, failure. (I.e. they punish 100success rates)