14

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!

2
  • 3
    I'm not sure that we can answer why your management is interested in A rather than B - seems to be me to be more productive to ask them, rather than us.
    – MCW
    Nov 17, 2014 at 12:23
  • 1
    I believe there is a good question in here about interacting with managers who use metrics for project management. Please re-craft it along those lines. Nov 20, 2014 at 0:26

3 Answers 3

15

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.

18
  • 1
    I really appreciate your time in answering my questions, and your every point is true to its core - I fully agree with it. Nov 17, 2014 at 11:58
  • 6
    Unless hours are billable, reporting them is generally a waste of time. The requirement to do so is often about relative status, not value. In organizations where everyone reports hours, this is probably not the case. But those organizations are few and far between. For organizations which require reporting hours, but don't expose those reports, the value to those reporting is almost certainly negative. May 29, 2015 at 5:37
  • 2
    Similar to Andrew I would have to disagree with this top-down approach. Specifically "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." In my experience, root cause analysis of this scenario will almost always lead to managers with poor reasons such as "my boss wants it" or "I don't actually trust the developers". If you want recent evidence of the negative effects of this "because I said so" management style, Google it, there's a lot out there - Drive, etc. :) Aug 7, 2015 at 19:58
  • 2
    Reading this more, I actually disagree with almost everything Venture is advising, basically top-down micromanagement and the opposite of modern agile values. The Scrum Master is not a master of the team in any sense of the word, they are 100% servant leaders and if anything, challengers of the status quo (which in this case means challenging hours tracking). I would even argue that most modern agile companies view everyone outside the delivery teams - including management - as servants to the team. In all seriousness Venture, I really recommend reading Drive, Joy Inc., Leaders Eat Last, etc Aug 7, 2015 at 20:05
  • 2
    Appreciated for the update @Venture2099 Apr 6, 2019 at 13:57
8

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 ;)
7

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

5
  • 1
    Niels - I think this will do two things. Management will demand a points to hours conversion table (and would be right to do so even though points are relative). The second is that a cursory glance at the hours v points debate will reveal the Mike Cohn blog where he succesffuly argues that all sprint tasks should be estimated in hours. Trying to circumvent management with agile esotericism will make the problem worse in my mind. Nov 17, 2014 at 8:15
  • 1
    The main problem I have with hours is that developers feel presure to finish the task at hand in this time-window. Leading to shortcuts and stress. While they should focus on quality and getting it really done instead of thinking the time is up for this task. Personally I like to measure in man-days, how many man-days does it takes to finish this task is easier to answer and less exact. Do you have a link to the Mike Cohn blog, googling leads to multiple results. I would like to read more and think about it. Since its always the same struggle with management... :) Nov 17, 2014 at 8:54
  • 1
    Hi Niels - this is the relevant blog post and Mike encourages direct challenge via the comments so I am sure he would appreciate your thoughts. mountaingoatsoftware.com/blog/… Nov 17, 2014 at 14:22
  • @NielsvanReijmersdal, I think the issue regarding developers feeling pressured to finish in the time window has more to do with how estimates are presented than the units of the estimate. My team estimates in "ideal person-days" and I emphasize that a) it is my job to convert that to calendar days for management, and b) the important thing is to get better at estimating over time, rather than to finish within the estimate. Nov 20, 2014 at 2:58
  • 1
    This is a nice counter balance to the accepted answer that keeps saying mgmt wants to see "value". The value is the working software. It does no good to work 80 hours if nothing works well enough to go to prod. ++
    – RubberDuck
    Jul 28, 2016 at 9:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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