Should Agile Product Owners track time?

[#1]

Time tracking in the Agile framework is a highly debated topic, especially with developers in Scrum Teams stating that it goes against Scrum Principles. But many Agile coaches agree that tracking time, as an individual activity and not a management requirement, improves performance.

Scrum and Agile Frameworks provide a high level of adaptability and have uncomplicated project management, ensuring that developers get more work done. However, picking the right tracking metrics is important to increase velocity and complete the project. 

Pros of Time Tracking

Time Tracking in Jira allows a more granular measure of a project’s progress. For example, Products Owners can view the hours spent on a Story and the number of hours remaining. In addition, any updates to the hours by a team member get auto-calculated, giving Product Owners a near accurate representation of Sprint's progress and help them resolve roadblocks if an issue takes longer to complete.

Custom time tracking tools with advanced functionalities turn assumptions of Story Points into precise decision tools. In addition, tracking developer time makes it easy to pull up historical data for future Sprints, Iteration Planning, Sprint Backlog, and Sprint Retrospective. 

They reflect reality, create transparency, and help track the project’s budget and predict project profitability.

Cons of Time Tracking

While it is widely agreed that time tracking has many advantages for a Scrum team, it can impede progress if not done correctly. Furthermore, asking your team to track time can harm the Scrum team if implemented as a micro-management technique, inherently against the Agile framework. 

Manual time tracking slows down the developers and results in a loss of productivity. In addition, there is an unfortunate probability that developers can ‘make-up’ timesheets resulting in wrong estimates, erroneous data, and a loss in billable hours.

Track your Time the Agile Way

While there is absolutely no direct correlation between time tracking and code quality, a Product Owner has responsibilities towards the management, customers, and stakeholders. If a project is taking longer than estimated because of changes in scope, timesheets provide detailed insights into the health of the project and the productivity of the Scrum team.

You can still enjoy the benefits of tracking time without it affecting the productivity of the Scrum team with a Jira custom reporting and time tracking app that assists developers in simplifying time tracking by automating the time monitoring process. These apps track time in real-time, providing Scrum teams and Product Owners greater visibility into the status of the Sprint. They also provide an accurate picture of what the team has spent time on and help determine inaccurate estimates and scope creep to continuously adapt and stay true to the core principle of the Agile methodology.

You have to decide which route to choose based on the nature of your projects, the people in your team, and your company's culture. As shown, both approaches can work. However, it's up to you to choose not only what works best but also what fits your culture.

[Bill Sheboy]

Hi community!

Thinking from a effort, value, and forecasting perspective, some feel that any time tracking is "essential, non-value-adding work"...until it isn't.

When a team's practices are such that they are unable to limit work in progress (WIP) well, a product owner and team may decide to track time (and other measures) as mitigations, helping them to provide stakeholders some idea of cost, progress, etc.  When a team is still improving on decomposing work items to releasable chunks of more consistent sizing, they may also decide to use relative sizing to help with progress measures: e.g. 21 out of 100 "story points" for an epic are completed.

When a team is able to focus and dramatically reduce WIP, tracking time (and sizing work items) may no longer be needed.  I have been successful having this conversation with controllers, allowing time/cost calculation and forecasting to be solely based upon the fully-loaded rate for the team, the start/end date of releasable work items, and the count of remaining items.

No pun intended, but "time takes time", and often teams cannot use such lightweight ways right away.  Working transparently to inspect and adapt, they can reduce any non-value adding work, while often satisfying stakeholders desires for improved predictability as partners in doing so.

Kind regards,
Bill

[Sedera Randria]

Interesting tdiscussion. Thank you @Andreas Springer _Actonic_ 

My experiences :

• When POs have to manage $$$, sometimes solutions such Jira+Tempo can help, save time and money
• When all the activities (days-off, trainings, projects, etc.) are in Jira and the tools are well setup/linked, I personally see benefits for me in using Jira
• When a corporate timesheet system already exists, why should Jira users enter time twice?
• When products are funded by iteration (or PI), with dedicated teams, what's the value of tracking time?