Just for contrast: I've been working for a medium size software house for the past 4 years. Typical project size is somewhere around 500 to 1000 man days. On that scale, individual days matter.
Still, I also have the impression that they matter because Clients demand certainty and precision in reporting rather than focusing on actual value delivered, but the management doesn't always see it that way.
Kind of. It's upper-medium.
It's nothing compared to Microsoft Office, a web browser, etc.
Microsoft for example has maybe 50k developers and so creates 50,000 man years of work every single year.
> Typical project size is somewhere around 500 to 1000 man days.
That's roughly 2 devs for a year. That's hardly even a prototype where I work.
It is fascinating to see the difference in scale in our industry.
It depends on the team.
We find it useful specifically because we want to make sure we are estimating relatively accurately. Since we work in essentially 10-working-day periods, it's great to know when a piece of work we thought we could easily achieve is actually a blocker, or much more complex than we thought.
Tracking progress goes on a Kanban board (or digital equivalent).
www.scrumguides.org/scrum-guide.html#events-daily
IMO, only for a small minority of tasks.
The vast majority of projects I've seen and worked on are measured in dev years of effort.
My current project is well over a thousand dev years.
In comparison a few days is meaningless.
Most often it's a trust issue.