-1

Situation: My company is using external developers. These developers are working in a Scrum setting with a delivery manager to manage the communication with us.

The team is very satisfied with the use of Jira. All estimates and hours spent are tracked which makes the (outsourcing) scenario very transparent. What isn't transparent are the hours spent on (scrum) meetings, hours of the delivery manager and other related activities.

What is the best practice to keep track of these kind of activities? I can imagine a situation where we possibly create separate 'user stories' to track these hours, but looking for a better solution.

  • 2
    What is the purpose for keeping track of this? Do you suspect the Team is slacking off? Is there a legal requirement to track all meetings? Do you suspect the Team is making a mistake with timeboxing the meetings? Are you just trying to gather data on a working Team so other Teams can emulate it? Something else? – Sarov Jan 15 '18 at 16:44
  • I agree with @Sarov, and would go further by saying that JIRA is a ticketing system rather than a time-accounting system. Using JIRA for billing or internal accounting seems like an X/Y problem to me, and likely merits a step back to understand the business problem you're actually trying to solve with this approach. – Todd A. Jacobs Jan 15 '18 at 18:31
  • Why would you want to micro-manage the situation? Are you approving their billing on Time & Material basis? Is that the reason? If that's is the case, you could very well track every task using Jira itself. What exactly is your challenge? – Devasuran Jan 18 '18 at 4:04
  • @Devasuran the challange is exactly as you describe. Are goal is not to track every micro-task, but because it is an external party, billing (related to hours) is quite important. – Citizen SP Jan 18 '18 at 7:59
  • 1
    @CitizenSP - in that case, you might want to change your driver for billing criteria from efforts to story points. Your contract should be to approve the billing when the story point is 'done'. The 'done' as in agile is different. It means the story point is up and functioning in the production box. This is because, you are mixing the paradigms (traditional and scrum) and that might cause challenge to your service provider. What-if your service provider just sends you the time-sheet for the sake of your approval indicating all the micro details you expect. Will that help you? No. so.... – Devasuran Jan 18 '18 at 8:38
1

Regardless of the methodology or project management approach you use, you always tailor processes to the needs of organisation and project.

Tracking time spent on meetings, communication and a thousand little things is most often a mission impossible. In these cases, I usually asked teams to keep a log of their activities throughout the day. This way I could balance the need for time tracking vs time lost on tracking the time.

  • Quick question(s): What if there is overrun? How will you know that your team is expending efforts on the tasks that you never anticipated to work on? I am sure you would come across such a situation. How will you handle those? Just curious to understand. – Devasuran Jan 18 '18 at 4:07
0

Scrum, by definition should afford full transparency into the amount of time participants spend in meetings. Meetings or "rituals" are practiced once per Sprint; time-bound; and ideally scheduled to occur at the same time each Sprint. A major benefit of Scrum is that it removes the need for meetings beyond the Scrum process. Make sure the Scrum process accounts for ALL (100%) of the time your team spends meeting about your project or account.

The best way to inspect the productivity of the meetings is to attend them yourself. If some of the activities practiced there are wasteful, suggest a change to the delivery manager.

Measure the performance of the delivery manager separately from the engineering team. Hold this manager accountable to demonstrate improvements in efficiency, velocity, and software quality. This manager should present you with a strategy for how these improvements are being sequenced, and should summarize risks or limitations putting a ceiling on their ability to enact productivity improvements. It may help to focus on results achieved, rather than number of hours worked, or tasks performed.

  • Please quote The Scrum Guide to support your opening statement; it sounds a lot like traditional project management misunderstanding of the pillar of transparency. Though process improvements may be gleaned from empirical information regarding events and meetings, it is certainly not required. – Alan Larimer Jan 15 '18 at 22:17
  • One defined event occurs more than once per Sprint: the Development Team's Daily Scrum. Scrum may not "remove the need or meetings" though the prescribed events may "minimize the need for meetings not defined in Scrum." – Alan Larimer Jan 15 '18 at 22:17
  • It also appears that the traditional 100% utilization fallacy might be a problem. – Alan Larimer Jan 15 '18 at 22:19
  • "Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team." Why should an outside person determine if an activity is wasteful? – Alan Larimer Jan 15 '18 at 22:21
  • Increasing velocity, which has been removed from the Scrum framework for many years now, is only applicable for teams new to Scrum and the agile philosophy; after that it's about sustainable pace. The implementation strategy is another violation of the concept of self-organizing teams. – Alan Larimer Jan 15 '18 at 22:22

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.