1

Developers at my company log hours in JIRA. Managers/Scrum Masters do not log hours that religiously. They would only log for Scrum ceremonies. As a manager, I can see the reason for not adding my Tasks to the Sprint, as meeting with stakeholders, helping team with technical difficulties, liaising with customers etc. are not good candidates for a developer Sprint. These cannot be planned nor groomed nor any such thing. And the Team doesn't need to know the details of these, as these are not the kind of Tasks any member should be able to do. Only I will be doing these Tasks and while I can ask for feedback from my Team, we don't need to groom these Tasks as such.

We recently had a conversation with HR, about finding a way to log managers' work. We can obviously create JIRA Tasks for our work, but then, as it doesn't get added to the Sprint, it doesn't get counted for the amount of work completed for a particular project.

Can you please share any insight into how you are managing this at your company? Do we create a separate Sprint for managers, across projects? Or do we create a Story in each Sprint for each category of Tasks I do during the Sprint, as a manager? We do have 6-10 managers with varying Team sizes assigned to each of them.

  • 1
    What is the goal of logging the manager's work? Who is going to use the breakdown, and to do what? – Erik Nov 27 '18 at 11:09
  • HR is going to use the breakdown. Mostly it would be an audit of the time spent and some insights into areas where people are spending time. They have this data for developers, but they dont have for managers. – shaibee Nov 27 '18 at 12:43
3

Analysis

HR is going to use the breakdown. Mostly it would be an audit of the time spent and some insights into areas where people are spending time.

This is a known anti-pattern. If the team is succeeding, then the Scrum Master (as part of the team) is contributing to its overall success. If the team is failing, then the Scrum Master (again, as part of the team) is failing alongside them.

The team succeeds or fails as a whole. Trying to tease out individual performance for team-based frameworks is an anti-pattern. The way to handle it is to educate the organization on how to effectively evaluate whole-team performance, not hijack ticketing systems like JIRA to track labor hours.

If you don't feel empowered to have that conversation, that's a problem too. Speak to your line manager, agile coach, or other project sponsor, and ensure that they are fully supporting Scrum's team-oriented culture. Doing anything else is an abdication of your responsibilities as a Scrum Master.

Recommendations

If the team is routinely failing to meet its Sprint Goals, then this is a problem for the entire Scrum Team to address during Sprint Retrospectives. Neither a traditional Project Management Office (PMO) nor Human Resources (HR)—and for goodness sakes, why is Human Resources even in this picture at all?!—should be involved in assessing intra-team processes or utilization.

While an agile community of practice is always a good source of advice and information, the organization should be looking at outcomes (e.g. "Is the team meeting its Sprint Goals more often than not?") rather than utilization metrics. Trying to convert individual hours into a value proposition is antithetical to core agile principles.

Tracking labor hours within the project is intrinsically a utilization metric, and to a lesser extent a cost-tracking or cost-accounting metric. When done properly at the program level, Scrum typically has an averaged run-rate per Sprint that is essentially fixed. Tracking labor hours instead of outcomes simply doesn't fit this model, except when the organization is violating core principles by matrixing teams or assigning people (a second anti-pattern) to multiple teams (a third anti-pattern). Don't do those things.

Don't enable organizational dysfunction or support known anti-patterns. Educating the organization on how the framework is meant to be applied, and how to be more agile in their business approach and interactions with the team, is an essential part of the Scrum Master's job.

One Caveat: Wage Accounting

If HR wants to know how many hours a day people are at work, or when they're taking time off, those are reasonable wage-related requests that have little to do with Scrum as a project management framework. Granular time tracking is an anti-pattern, though, so make sure you don't have an X/Y problem here.

Say "no" to utilization metrics, but by all means use techniques like the 5 Whys to understand the real problem that HR is trying to solve for. You may be able to help them solve for X rather than Y without damaging your Scrum implementation.

  • Could it still be useful if the results were aggregated among the Team? Rather than "Bob is spending too much time talking to the customer", "Team A is spending twice as much talking to the customer as Team B. But their Sprint Goal-success-rate is three-times higher. Maybe we should tell other Teams to follow what Team A is doing."? Or "Team C is spending 300 hours a week in meetings...". – Sarov Nov 27 '18 at 14:14
  • @Sarov If the team is failing to meet its Sprint Goals, then this is a problem for the entire Scrum Team to address during a retrospective. Neither a traditional PMO nor HR (and for goodness sakes, why is Human Resources even in this picture at all?!) should be involved. While an agile community of practice is always a good source of advice and information, the organization should be looking at outcomes (e.g. "Is the team meeting its Sprint Goals more often than not?") rather than utilization metrics. – Todd A. Jacobs Nov 27 '18 at 14:17
  • Fair enough, now it makes sense to me - you might want to add that to your Answer. – Sarov Nov 27 '18 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.