Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
stylenone

...

First, for any given day we find all actions a given user has. Actions include any commits or card activity that user has. Note: We skip weekends when considering a users FTE’s. This means that for any given week, a user can have a maximum of 5 FTE’sFTE days.

Then, we loop through the list of actions and run a calculation to find that actions FTE ratio.

...

  1. Allocation shows information in terms all stakeholders can understand

    1. Stakeholders don’t always know how many card actions or commits per day to expect. However, often they do know how much they’ve budgeted for things, and how many working hours they’re expecting to get out of their teams.

  2. Allocation normalizes data across teams that work very differently

    1. Metrics such as velocity, commits, and PRs skew toward teams that do smaller increments more frequently. Just because a team does twice as many tickets doesn’t mean a team does twice as much work. Allocation smooths this out so teams can be compared to one another or aggregated together more effectively

  3. Allocation can be a zero-effort replacement for time tracking

Areas for Improvement

...

Tier

...

Description

...

Notes/Questions

...

1

...

RBAC to control who can see this metric

...

We are establishing temporary work arounds to enable experimentation

The permanent fix for this will take more research and definition to figure out how this factors into our RBAC regime.

...

1

...

Commits are not linked to tickets correctly

e.g. This developer is showing as ~50% categorized in Allstacks, this is due to those missing linkages between tickets and Commits.

...

n.b. Merge commits should be connected to tickets as well. That said, they should be filtered out in most cases.

...

Queued up to be resolved.

...

1

...

Establish a maximum amount of time attributed to an action after a long time of inactivity. 

e.g. On a Monday, A developer takes an action which begins attributing time to that ticket, they take the rest of the week off. Time is still being attributed to that ticket.

...

What do we think that maximum should be?

...

2

...

Shuffling tickets in a backlog shouldn’t count as working on those tickets

e.g. I move a ticket up in the backlog and take lunch. This action took seconds, but time will be allocated to this ticket until their next action

...

2

...

First action of the day needs to receive a minimum credit

...

2

...

Pull request activity should be counted and properly linked

...

2

...

Weekend activity should get credit when it happens, otherwise weekends should be ignored

...

Frequently Asked Questions

Q: Can I create special roles so that only certain users can see Allocation metrics?

A: If you want to limit access to Allocation to select users, let your Allstacks representative know which users you want to have access, and we can set that up for you. It’s not currently a role or permission that customers can manage for themselves.

Q: Why are some commits showing up as uncategorized?

A: For Jira, commits need to have the ID for the card they belong to in the commit message to be linked to those cards. In ADO, commits need to have the card ID in the commit message, or in a PR that’s linked to a card.

Q: What happens if a contributor goes on vacation? Is there a maximum amount of time that Allstacks will attribute to their first action when they get back?

A: Currently, a contributor will get credit for all the business days between their last action and their next action. In the future, we plan to have a maximum amount of credit that can be attributed to an action, and allow that max credit to be configured by the customer, so these situations don’t skew the data.

Best Practices

  1. Filter out the Merge Commits from this metric.