1

So I am just joining a new team. This team is using "Daily Scrum" as a task because according to them it is a "task".

Obviously I want to help them understand that it is not a task, just like logging in to your computer isn't a task. The only question I anticipate is, "then how do we note the time spent in these activities". As of now, I have only one suggestion. "Consider these activities as part of the actual task itself". For example, a bug fix requires planning, testing etc. Those should be included in the estimate, not considered as separate activities.

Now, two questions. First, is my approach to this possible question correct? Can I help the team understand this better?

Second, can I just stop the team from counting hours spent in these activities? I can just track them myself, on my side, to see if we are improving. Obviously, then I will have to reduce the efforts per day to account for the change in estimation. E.g. going from 8 hours per day to 6 hours per day, plus 2 hours for other essential activity. Will this be a better approach than just increasing estimates for actual tasks?


There are a lot of other bureaucratic processes here in place. It is not Scrum but rather Scrumbut. :( I am planning to take up the task to fix this. That's why the question. And yes, they have a bloody task called "Communication strategy" where they log hours for internal team discussion. I have been told it is because current PM wanted to track that. I don't care if they spend 3 hours discussing a solution instead of spending 6 hours in analysis. That's why I want to find the best way to get the team to start focusing on actual deliverable piece of work, and not on this.

  • On a different note, can we add a permanent task board for activities like daily scrum? Just in case, client wants to see the amount of time spent in the same. – jitendragarg Oct 9 at 10:36
  • "going from 8 hours per day to 6 hours per day, plus 2 hours for other essential activity" - what exactly constitutes this 'essential activity'? – Sarov Oct 9 at 15:42
  • Mostly, jira updates, emails, reporting etc. There is a lot of bureaucratic overhead in the current product. Plus they do daily release to staging environment manually. Yes, manually. So, while I wait for CI pipeline to be created, I will have to deal with the "essential activities". That's the term of current PM btw. – jitendragarg Oct 10 at 7:36
1

I assumed here that by 'other essential activity', the OP meant administrative work/meetings similar to the Daily Scrum. The OP has clarified - leaving this Answer for posterity.


E.g. going from 8 hours per day to 6 hours per day, plus 2 hours for other essential activity.

Why do you have two hours of daily administrative work??

The Daily Scrum should take five to fifteen minutes. You probably should not have any daily meetings other than the Daily Scrum.

I once worked in a Team where the Team had asked the boss that they start tracking time spent in meetings in his office. The reason they asked is because they spent an average of 5-15 hours per week in there, and they wanted the boss to realize that and stop it, but were too afraid to ask outright.

As others have said, you should talk to the Team to ask them why they think this time needs to be tracked. However, you should also think by yourself about whether there could be something the Team doesn't feel safe telling you, and that this is a cry for help (or a quiet cry of defiance).

(Another possibility is that your Daily Scrums are taking 45 minutes. The Team is telling you to stop that.)

  • 1
    It is pretty standard to assume you only get 6 hours of productive work on tasks into an 8 hour day. That doesn't mean you have more than 15 minutes in your standup. – nvoigt Oct 9 at 15:03
  • @nvoigt Sure, but that's due to things like bathroom breaks, random discussions, burnout, emails, etc. Things that most would never track. I'm under the impression that the OP was talking about more bureaucratic processes, such as the Daily Scrum. – Sarov Oct 9 at 15:16
  • There are a lot of other bureaucratic processes here in place. It is not Scrum but rather Scrumbut. :( I am planning to take up the task to fix this. That's why the question. And yes, they have a bloody task called "Communication strategy" where they log hours for internal team discussion. I have been told it is because current PM wanted to track that. I don't care if they spend 3 hours discussing a solution instead of spending 6 hours in analysis. That's why I want to find the best way to get the team to start focusing on actual deliverable piece of work, and not on this. – jitendragarg Oct 10 at 7:33
  • @jitendragarg Oh, well there's your problem. I'll make a separate Answer to explain. – Sarov Oct 10 at 13:15
  • 1
    @jitendragarg That's my point, though. Don't. Don't come up with something on your own, try to anticipate all arguments against it, and bring it to them. Instead, involve them from step 1. Build it collaboratively. – Sarov Oct 15 at 17:48
4

No team I ever met was self-motivated to fill out bureaucracy tickets.

The question you should ask is: who wants them to count hours and why.

Then find out how to solve that need.

Ideally, you have a capacity for each team member and that capacity goes down when you have meetings. A person there for 8 hours per day might only have 6 hours of capacity. Because there are daily meetings, restroom breaks, unrelated company specific paperwork to fill out, emails to answer etc.

  • 1
    That's the stupid thing that we have in India. Since the client is billed by 8hours, companies track 8 hours of "productivity" which is obviously impossible in a 9 hour day. And there is literally no buffer ever. Got delay? Work overtime for free. Extra scope? Work overtime for free. Literally every organisation here does this. That's why devs count time in stupid things like "sending email for 1 hour". I can get that fixed, but then I will be counting 6hours of productive time, which means I have to explain to management why I am doing so. I am currently unsure how to approach them on this. – jitendragarg Oct 10 at 7:39
  • 1
    @jitendragarg it seems your client is not buying into Scrum. If you do Scrum, it's the results that count, not time spent on individual activities. I understand that you're in a weak position educating the client about this, and frankly I'm not aware of a magic bullet to do this. – Hans-Martin Mosner Oct 10 at 7:47
  • @Hans-MartinMosner I understand that management and client needs to buy into Scrum. But before that I need to empower the team to actually take decisions or at least suggest the changes. For now, it is "management asked for it, so we do it". I want to start with small changes first, that's why focusing on team first. I want to know if I can get the team to agree on new system, and if I should expect any push back. As for management, I will cross that bridge when the time comes. – jitendragarg Oct 14 at 13:45
1

There are a lot of other bureaucratic processes here in place. [...] they have a bloody task called "Communication strategy" where they log hours for internal team discussion. I have been told it is because current PM wanted to track that.

There's your problem. Your Team is under the (apparently correct) impression that the culture of your workplace necessitates pointlessly tracking every last nitty-gritty detail. So why wouldn't they track the Daily Scrum? They've probably just given up on following a rational process.

Tracking the Daily Scrum is a symptom. The culture is the cause. Start asking 'why'. Find the person/people responsible for the culture, and ask them (non-confrontationally! Come at it from the perspective of trying to understand, not attack) why the current processes are necessary.

Maybe you'll actually get a reasonable answer. That's fine - communicate it to the Team so that they understand why they need to track certain things, and therefore stop tracking other things purely because of a cargo cult.

Or maybe you and they'll come to the realization that there isn't a reasonable answer and the Team shouldn't do all this bureaucracy.

0

I would ask, why are you counting hours in the first place? User story estimation is meant to be based on complexity not 'hours spent'.

  • It is not estimation. Team is counting the hours spent. BTW, this is current system that I am planning to change, to make it more sensible. – jitendragarg Oct 10 at 7:30

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.