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!

Tiago Cardoso
  • 8,645
  • 6
  • 29
  • 72
Knowledge Craving
  • 253
  • 2
  • 8
  • 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 '14 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. – Mark Phillips Nov 20 '14 at 00:26

3 Answers3

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.

Venture2099
  • 4,075
  • 18
  • 38
  • 1
    I really appreciate your time in answering my questions, and your every point is true to its core - I fully agree with it. – Knowledge Craving Nov 17 '14 at 11:58
  • I have one more question, though. I sometimes check the burndown chart of JIRA (v 6.4) and report how many hours have been logged for the day. But I don't find any way to have a list of those members who didn't log hours for any day. Can you please help me with any proper JQL (JIRA Query Language) or any other way? Thank you, again! – Knowledge Craving Nov 17 '14 at 12:03
  • Unfortunately I do not use JIRA, although other departments in my organisation do. I could staff the question to them if you are happy to wait 24 hours? I suspect CodeGnome or Niels will have a better depth of understanding for JIRA and I would recommend approaching them. – Venture2099 Nov 17 '14 at 14:26
  • 1
    Venture2099 - No issues at all, I got the solution yesterday:-
    1. Navigate to the desired project.
    2. Choose Summary (tab) > Reports section > Time Tracking Report.

    Thank you!

     – Knowledge Craving Nov 18 '14 at 06:09
  • I like the emphasis on the team not having the value explained to them. Oftentimes I find the stress around hours reporting is at its core a communication issue. – Andrew Clear Apr 05 '15 at 17:41
  • 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.

     – Andrew Prock May 29 '15 at 05:37
  • @AndrewProck - clearly you did not read my answer. We will have to agree that we disagree. The requirement to bill/track hours is almost ALWAYS about tracking value. – Venture2099 May 29 '15 at 07:36
  • 1
    I read your answer. Not sure why you would assume I did not. That's a bit rude actually. – Andrew Prock May 30 '15 at 06:14
  • @AndrewProck it is not rude at all to assume you did not read my answer. I came very concrete and valid reasons for tracking hours. The post is the most upvoted and has been marked as 'the answer'. However your response was a throwaway couple of lines essentially saying "this answer is wrong, reporting hours is negative value." So yes...I assume you didn't actually read what I had wrote. – Venture2099 May 31 '15 at 06:48
  • While there are valid arguments here for time tracking (even though I'd disagree with a lot of them), it doesn't address the issue of JIRA. And that's actually a giant monkey wrench. A lot of management want to use JIRA as a time tracking tool--which it simply isn't. And in many ways messes with the Agile process JIRA is actually supposed to be assisting with. – DA. Jul 21 '15 at 17:37
  • As for my opinion of time tracking: https://www.youtube.com/watch?v=_ogxZxu6cjM – DA. Jul 21 '15 at 17:38
  • 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. :) – Jeff Lindsey Aug 07 '15 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 – Jeff Lindsey Aug 07 '15 at 20:05
  • You have made a fundamental mistake @JeffLindsey. You have assumed that I personally support time-sheeting. I don't. I pushed back against it and won that small victory for my team. However, too many people in the Agile community feel that all battles can be won against senior management which is simply not true. Sometimes "they" win and Agile principles take a back seat. That is reality. So my answer started from there. You can disagree with me but you cannot change the world and every corporate governance structure. My leadership pedigree is pretty well-informed and I read widely. – Venture2099 Aug 08 '15 at 20:24
  • If you walk into an regulatory audit for a PLC and they ask for time-sheets you better have them. The agile principles will not stop you being out of a job that day and a new "Agile PM" being drafted in who has the ability to blend the requirements of fast delivery with the normal working practices of a Programme Management Office. We can spend all day chatting about the aspirational working practices we want but don't try and paint that as the reality of the world because it simply isn't. Also, the ScrumMaster absolutely is the Master-Servant of the team. – Venture2099 Aug 08 '15 at 20:27
  • 1
    Show me in the Agile Values where it says every single employee is highly self-motivated and always delivers value and seeks professional development...show me where it says that individual resources split across multiple projects should not track the hours they spend supporting those differing projects...show me where it says Agile is incompatible with a regulatory environment. It doesn't. It's a set of values which have to be interpreted uniquely in each environment. – Venture2099 Aug 08 '15 at 20:31
  • Changed my career from a PM to a developer, now I know how this logging hours idea sucks. If I need to log my hours spend on each task each day, it is valid and doable. However, Jira forces people to log the start time which will be a problem...Very hard to figure out the exact time at the end of day, and if you dare to log the time after each work, will be hard to handle the multi-tasking and delay the procedure. – Albert Gao Jun 13 '17 at 21:57
  • 2
    Appreciated for the update @Venture2099 – Tiago Martins Peres Apr 06 '19 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 ;)
Sarov
  • 14,768
  • 5
  • 33
  • 62
WBW
  • 3,932
  • 12
  • 20
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

Niels van Reijmersdal
  • 5,553
  • 20
  • 32
  • 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. – Venture2099 Nov 17 '14 at 08: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... :)

     – Niels van Reijmersdal Nov 17 '14 at 08: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. http://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning – Venture2099 Nov 17 '14 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. – Vicki Laidler Nov 20 '14 at 02: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 '16 at 09:58