Scrum Time Tracking is Anti-Scrum

When I hear this, the first question I am struggling to get an answer for is. 

• what is the benefit of adding a user story or task for a scrum event? 

• What is the value to the user or customer tracking, outside of the other user stories that deliver value to the customer in the form of a potentially shippable product?

I usually encourage our scrum masters and product owners and agility practitioners to find out the "WHY" behind what is being asked of them. If this is for billing "tracking time", the Scrum events do not need to be recorded on the product backlog or the swim lane in the scrum board in my opinion. 

In the old and new Scrum Guide, each event is distinguished with a suggested time box for each of them. Each artifact is describing separately on purpose and the way I look at it, the Sprint/Iteration Review and Sprint/Iteration Retrospective are the last events that signify the end of work of the Iteration/Sprint.  On the other hand, with the Sprint/iteration Planning, this is in place to kick off a Sprint, the daily standup as the execution, and not every team utilizes grooming or refinement.  

My suggestion is to add stories into the Admin Sprint Backlog to account for people updating their timesheets or attending meetings with HR for annual reviews.  That would be "work" done during the Sprint but has nothing to do with the work needed to accomplish the items pulled from the Product Backlog. At the end of the day, the focus needs to be on what is being delivered in the committed time. 

I came across a blog post by Jeff Sutherland | Aug 3, 2012, where he made a recommendation on this topic. “For those organizations not billing in hours, we recommend abandoning time tracking completely and go to only relative point estimate”. Click here to read more