4

I've recently taken over a project from another scrum master.

In the backlog there is a 'Feature' called 'Support HW Team' (HW -> Hardware) that has a bunch of vague stories under it and basically never gets closed because it's ad-hoc, ongoing work.

What is the best practice for planning and tracking this sort of work? I don't like these never ending Features because they end up becoming massive and hard to groom. Also, they get used for burying hours as they're always part of the sprint and devs can legitimately assign almost any time they like to them without much pushback.

I'm more familiar with Jira than Azure boards but I don't recall a neat way of doing this in Jira either.

3
  • 1
    Two questions. 1. Why do you need to track 'Features'? 2. Why do devs need to track their time?
    – Sarov
    Jul 8 at 13:09
  • 1
    1. Why do you need to track 'Features'? - Never said I did. The problem is historic to this team. 2. Why do devs need to track their time? - Primarily because some activities qualify for R & D tax refunds and some don't. If you get audited, you need to provide proof and the board is perfect
    – Edgen
    Jul 8 at 13:16
  • 1
    Sounds like invisible work to me. The two standard approaches to invisible work are either to make it visible - if the work is involved in the team's promise to deliver the sprint, then it should be planned as part of the sprint. no vague stories. If the work isn't involved, then make it invisible - most teams plan for 80% staff availability. Have a conversation with your management about recognizing that tasks outside the sprint diminish the effective availability to 70% or 60% or less. One opinion, worth what you paid for it....
    – MCW
    Jul 8 at 18:05
4

Between

Why do you need to track 'Features'?

Never said I did. The problem is historic to this team.

and

Why do devs need to track their time

Primarily because some activities qualify for R & D tax refunds and some don't.

My suggestion would be to reduce everything down to just two 'Features':

  1. R&D Tax Refundable
  2. Non-R&D

It simplifies everything and makes it clear what you're tracking and why.

As a bonus, speaking as a developer, I would push back hard on a time-tracking scheme 'just so we know how exactly much time you spend on what', but wouldn't push back at all on this (since it's obvious why it's needed (taxes) and simple (just make sure your times to the two 'features' add up to 8 hours)).


NOTE: The above assumes it is straightforward whether a piece of work qualifies for the Tax Refund or not. If that is not true, then, as @detly suggests, identify distinct activities that probably qualify. That being said, you can still just have a generic 'Non-R&D' bucket for vague stuff that you know isn't tax refundable (and thus you don't care what it is). With this approach, if you end up being wrong about a particular type of work, you can just destroy that particular Feature and translate everything in it to 'Non-R&D'.

5
  • 1
    With my auditor's hat on, seeing two categories like that would raise the obvious questions "how do all your devs know which category each task they do falls into?" and "when booking mistakes happen in those two categories, how can you identify and fix them when you don't know what any of the work actually was?" I have no idea if the OP will ever be audited either internally or externally, of course. But if you know nobody will ever audit the bookings, you don't even need two categories - just make a plausible guess at how to split the total, and nobody will ever care how accurate you were.
    – alephzero
    Jul 9 at 1:30
  • 1
    @alephzero Isn't the first answer obvious? They know whether they're doing R&D work or not. If your devs don't know the difference between R&D and a bugfix, you have a bigger problem than auditing. It's possible I misunderstood the OP and there should be a third category, 'R&D Non-Tax-Refundable'. In which case, the devs may or may not know, but the one defining the stories still should. For the second question, I'm not sure why you say "you don't know what any of the work actually was". Just because a story has the wrong Feature assigned doesn't mean it has no other identifying information.
    – Sarov
    Jul 9 at 13:37
  • "If your devs don't know the difference between R&D and a bugfix, you have a bigger problem than auditing." Sorry, but in Australia at least, this is wrong. The R&D definition is set by the government, and may change over time, although it is always known in advance of the work. It does not necessarily line up with what a developer or company might call "R&D" and generally requires someone qualified in tax or business law to delineate.
    – detly
    Jul 12 at 3:30
  • In general (and still in the context of Australian law) the easiest way to navigate an audit of this is to (a) identify distinct activities that probably qualify (b) justify why they qualify and (c) allocate staff time to these activities. That way, if an auditor disagrees with any subset of those activities qualifying, the accounting goes from "interview every engineer about what they did and when over a twelve month period from two years ago" to "remove a column from a spreadsheet sum".
    – detly
    Jul 12 at 3:33
  • 1
    @detly Interesting; I wasn't aware of that. Thank you. I've updated my answer.
    – Sarov
    Jul 12 at 14:08
3

You say you can get audited and that you do some R&D activities too. Does the company you work for need to comply with specific regulations or standards? If yes, that would be the where I would start.

If your auditors or tax people require certain information to be available then try to identify the work that falls in these categories and split them from the generic "support feature".

Then I would look at what work the developers usually dump into the generic "support feature" to see if it makes sense to split further categories from that.

Basically, you need to create some work categories and define the criteria for which work will fit into one or another category. Sarov suggests just two categories in another answer. You might discover you have others. My suggestion is to keep it simple. Don't go all in to create many tiny categories, but start with a few large ones and split them later if needed or asked to by auditors or tax people. Remember that if you get audited you will have to explain the categories, and it's easier to explain a few than a lot. It also makes it less stressful on people in your team. Go for transparency not for a bureaucratic process.

1
  • 1
    Auditors want to audit the process, not the output from it. For example a reasonable process would be (1) Identify packages of work that have start and end points (not open-ended "ongoing support for XYZ" bucket job numbers) (2) Devs book their time against those packages (3) Somebody assigns each package as tax-refundable work, or otherwise (4) Calculate the total tax-refundable spend. The key point is that each of the four steps is checkable and independent of the other three steps.
    – alephzero
    Jul 9 at 1:47

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.