Why management is more concerned of JIRA hours than of following Scrum values?

Question

As in many other projects, we are also using JIRA to manage tasks and user stories, and Scrum as the Agile methodology. At the end of each day, the ScrumMaster provides the burndown chart to the PMO team.

However, the first set of questions that get raised during each weekly meeting with the PMO team, are:-

• Why is the team not burning hours properly in JIRA - 5 hours per day?
• If each team member is burning hours (~ 5-6 hours per day) and logging them properly in JIRA, then why is the red line (of Remaining Values) in burndown chart not coming down as close to the Guideline?
• Who in the team is not logging hours?
• Why the team has to be reminded each day to log hours in JIRA?

Frankly speaking, the whole team is quite fed up with all these silly questions, and all of us wonder whether we are actually following Scrum values, or instead just maintaining JIRA to show PMO that we are all following Scrum and have a near-to-perfect burndown chart.

For me, I have always been wondering on three points:-

• Why the management is more concerned of JIRA burndown chart than of following Scrum values in project development?
• Why do some members of the team don't like to log hours in JIRA diligently every day?
• Is there anything that the team can do to make this logging of hours (by each team member) a more easy process, so that the management does not bother us by asking such bad questions?

Can anyone of you please clarify my above-mentioned three doubts, so that we all can become a better Scrum team?
Thank you all in advance, and I appreciate your time and suggestions to help me!

Answer 1

I can feel the frustration in your post. As someone who made the transition from a PMO to an Agile role I can understand both sides of the coin.

Your question has multiple components which I will take in turn but all of them have effective communication at their core.

Why are management more interested in logging hours?

This could be a number of things but management absolutely must track hours of work accomplished. It could one or a combination of the following reasons.

• The company must account for shareholder value being invested. Effective delivery is only one way of tracking value, it is also necessary to ensure that the delivery is roughly allied to the amount of predicted hours of effort.
• External auditing and governance compliance. If your company is a PLC then the auditing and regulatory burden increases and logged hours are a critical component of that process. Remember; when someone gets their monthly salary that is someone's shareholder investment being transferred across and that shareholder expects a minimum level of return on investment for paying that salary. It is not unreasonable to simply log hours worked is it?
• Timesheeting. If you are attached to a PMO it is likely the development team have multiple project or programme workstreams coming in. The department is not a free resource, your developers need to be apportioned to a cost centre for the work they do so that projects can be tracked to ensure they are on budget.
• Resource Demand. Do not underestimate that the primary way management decide to scale up and down resource is by contrasting planned effort in man days / man hours against a fixed dead-drop timeline. If the resource demands exceed the deadline they will bring resource in. Logging hours is a critical part of ensuring that planning is effective and accurate. You get additional developers and testers if required but logging hours is critical to making that business case.
• Trust. Right now it appears management have some trust issues regarding the department. It is possible you are a fledgling Scrum team, the process is new to them, it was not sold in the right way or they need to control the full time resources of the department. All of these symptoms are a lack of trust.

The hard truth is, I would never allow an employee to forego tracking his/her hours if he cannot even manage to track his hours. Does that make sense?

In the military we used to have a saying -

"When you can administer yourself, we will give you a rifle. When you can administer your rifle, we will give you a vehicle, When you can administer a vehicle we will give you subordinates..."

If your team cannot even accomplish hours tracking then why on earth should they be released from the task? It's a simple item that takes less than 5 minutes. I am surprised management has not taken more stringent action already. If your team want independence they have to earn it.

Why are my team not logging hours?

This is partially a psychology issue but it also indicates they have not had the value of hours tracking explained to them. If they have had the value explained and they continue to discount a process that Management feel is valuable then you have a dysfunctional team, possibly centred on one or two strong characters who are driving the rest of the group.

In that instance you must take action to instil discipline in the team. A Scrum Master is the master-servant of the team. Most people focus on the servant part to show humbleness but do not forget the master role. Impose your will onto the team to ensure they understand exactly what will and will not be tolerated.

Communicate to the team that

• Hours must be logged at the end of each day
• You will consolidate all logs daily and report on those missing
• Consistent offenders will have it reported on at their annual appraisal
• Consistent offenders are letting the team down because the sooner they comply the sooner management may trust the team and remove the process

It is always easy to blame the management process rather than do a root cause analysis; in my experience most managers have sound reasoning for the reports and processes they request. Also, in the future if you need to scale up or challenge planning estimates and you don't have logs supporting your business case then expect the resources to go to a department head who can enforce logging.

Good luck, even raising this issue in PM.SE indicates you have some excellent qualities to fix the issue.

2019 Update

This answer represents a snapshot in time of where I worked and how I approached Agility. I should say that, nowadays, I absolutely do not support time sheeting and timesheeting itself is symptomatic of a project smell which requires root cause analysis. It indicates lack of trust in a team or resources split across deliveries. It is, in short, a terrible way to facilitate software development.

In addition, working software is the primary method to demonstrate value. All other artefacts are smoke and mirrors.

I stand by my answer as it shows the journey that we all take towards the Agile values but I no longer support it as advice to the development or project management community.

Answer 2

Why is management is more concerned of JIRA burndown chart than of following Scrum values in project development?

3 common reasons for this type of behavior are:

1. Lack of trust
2. Poor understanding of Agile methodologies; still thinking in waterfall terms
3. Delivery Team is not meeting commitments

Why do some members of the team not like to log hours in JIRA diligently every day?

Its either perceived as a waste of time, or the team member doesn't understand the value of performing the activity, or they haven't received reinforcement on continuing this practice.

Is there anything that the team can do to make this logging of hours (by each team member) an easier process, so that the management does not bother us by asking such bad questions?

• Build trust
• Honor commitments
• Educate PMO on agile methodologies
• Show them an alternative way for tracking the progress of work
• Fire current PMO, and hire one that understands Agile ;)

Answer 3

To make it easier to log hours in Jira you can use the worklog assistant program. The worklog assistant grabs all filters from Jira, you get a list of the current sprint issues for example. It warns you when not logging time. Its possible to publish automatically or do it manually and correct some logging when needed. Create some place holder tickets for down time like sprint meetings and or other non sprint overhead.

Not sure if you do, but don't estimate tasks in hours, switch to story points (this is supported by Jira). For management its harder to convert done work into hours and compare them. Work is done when its done, not when the team estimated it. Some tasks will take longer others will take shorter. The burn-down is there to give insights if you are going to finish your forecast and adapt accordingly if the plan does not come together.

I think management is worried about hours, because they pay developers per hour. Every hour is extra money. Explain how Scrum gives developers more focus and that its harder to side-track on non important things.

I once was at a Scrum introduction by Jeff Sutherland and he said that the first thing he changes in a company is to remove time tracking. Also read his blog post Time Tracking is Anti-Scrum: What do you do when you need it for billing?

It was generally agreed in a Scrum training class in Copenhagen yesterday with experienced project leaders operating at CMMI Level 5 at IBM and elsewhere that asking developers to fill out time sheets reduces team productivity by at least 10%. They hate to do it, it is duplicate work, it is obviously “waste”, and is only done by companies that do not have a clue about lean product development