Somewhat related to #1, we want to remove the concept of sprints from our output for kanban/lean Jira projects. We should instead just refer to "days"/"weeks"/"fortnights"/"months".

When it prints out the predictions, after each result line, also print a line that shows the confidence percentage and cumulative confidence percentage graphically so you end up with overlapping bar charts.

I don't think I can show what the terminal colours would be in this example, so I'm using symbols to illustrate. Also, the bars should probably be a lot longer than I'm showing here. Maybe as long as the terminal window can fit.

2 sprints (4 weeks), 30% confidence (predicted by 296 simulations)
██████░30%░░░░░░░░░░
3 sprints (6 weeks), 68% confidence (predicted by 351 simulations)
████████▒38%▒▒░68%░░
4 sprints (8 weeks), 96% confidence (predicted by 248 simulations)
██████▒28%▒▒▒▒▒▒▒▒▒░96%
5 sprints (10 weeks), 99% confidence (predicted by 25 simulations)
█▒3%▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 99%
6 sprints (12 weeks), 100% confidence (predicted by 10 simulations)
0%▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒ 100%

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• Update actions/setup-node action to v4
• Update dependency node to v20
• Update dependency prettier to v3
• 🔐 Create all rate-limited PRs at once 🔐

Edited/Blocked

These updates have been manually edited so Renovate will no longer make changes. To discard all commits and start over, click on a checkbox.

• Update dependency jira-client to v6.23.0 (jira-client, @types/jira-client)

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency node to v16.20.2
• Update dependency prettier to v2.8.8
• Update dependency ts-node to v10.9.2
• Update dependency type-coverage to v2.29.0
• Update dependency typescript to v4.9.5
• Update actions/checkout action to v4
• Update dependency @types/jira-client to v7
• Update dependency jira-client to v8
• Update dependency typescript to v5
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

When performing sprint-based forecasting, it is reasonably simple to determine whether introduced work delayed other work - there is a clear signal that work was brought into a sprint and then other work was prioritised over it.

Outside sprints, we can consider other signals that indicate a ticket was intended to be completed:

1. top X of backlog
2. a particular (perhaps project specific) status

In output like

Resolved 2 tickets in sprint 1.
Resolved 3 tickets in sprint 2.
Resolved 7 tickets in sprint 3.
Resolved 5 tickets in sprint 4.
Resolved 10 tickets in sprint 5.

The numbers in "sprint 1", "sprint 2", etc. aren't meaningful to the user. Let's change it to print the date ranges instead. That would also be useful when you're running the script regularly and saving the results so you can see how accurate the predictions were and whether they're getting better or worse.

For example:

Resolved 2 tickets in sprint 2021-03-01 to 2021-03-14.
Resolved 3 tickets in sprint 2021-02-15 to 2021-03-01.
...

Originally posted by @kn-ad in #2 (comment)

My memory is foggy, but I think this only works with kanban boards (JIRA_BOARD_ID). We should see what it would take to expand this to support both kanban and scrum boards.

There are a few scenarios where a ticket gets closed with little or no effort. Examples include:

• Tickets closed as duplicates
• "wont fix" tickets
• Tickets that were accidentally fixed elsewhere
• Tickets that are no longer relevant for whatever reason
• Tickets that have no time logged against them

We should add an option to exclude these tickets when evaluating past performance (velocity, ticket close rate, etc).

The assumption here would be that the ticket being inquired about (the target ticket) and all tickets ahead of it in priority order do not fall into this little/no effort category, so there is no value in including such tickets for forecasting. Including them would give us an artificially high forecast.

Are BUG_RATIO and DISCOVERY_RATIO fundamentally different, or could we simplify our lives by having a single ratio for “new work”? Does treating them separately give us some benefit? Greater accuracy?

Currently we force users to provide a single ticket as the target for forecasting. It would be good to expand this to other things.
Examples: "when will all tickets in epic x be done?", "when will all tickets with label y be done?"

The consequence of not including these is that our forecast will be lower than it should be. This is sort of the inverse of #18.

The model currently assumes that tomorrow's velocity will be the same as yesterday's. It might be useful to teach it to understand common reasons why this might not be true:

• team size changes (new team member, existing team member leaving)
• resource allocation changes (existing team member moving from 100% allocation to 50%, or vice versa)
• upcoming (predictable) leave (annual, public holidays, etc)

You could start with allowing the user to specify this stuff manually, and then build on it by tapping into leave calendars and the like.

If a ticket has a fix version it will no longer appear on the kanban even if it's still in progress.

I'm not sure how tickets end up in this zombie state, but I've seen it happen more than once.

Such tickets are currently included in our in-progress + to-do ticket list, even though we shouldn't consider them truly in progress or to do (because no scrum master is going to be considering them and nobody is going to be working on them).

We should update our JQL to exclude these.

Using io-ts to parse responses from Jira should get us to 100%.

Technically true, but probably on the confusing side:

1 bug ticket created for every Infinity non-bug tickets.

Replace it with something along these lines?

Bug tickets never created.

or

No bug tickets created.

We currently assume all work is happening in a single project (Jira key). There are some cases where a board contains tickets from multiple projects. We should probably support this.

Currently, all tickets are treated the same (the simulation draws no distinction between ticket type or size or complexity or story points or time estimates or anything else).

This is done for a good (if perhaps surprising) reason: tickets spend the vast majority of their lives in "waiting" states (backlog, waiting for QA, waiting for UAT, waiting for deployment, etc). For this reason, the size of individual tickets doesn't have a meaningful impact on delivery time (or so the reasoning goes). Another argument is that this liberates our forecasting from estimating (e.g. story pointing) which is subjective...

I tend to agree with all that, and it certainly makes our forecasting algorithm simpler, but I can't help feeling like there are certain projects and certain team arrangements where this forecasting breaks down. Consider an example where you have a highly heterogeneous team, consisting of specialists with non-overlapping skills. There are going to be tickets that can only be worked on by certain people on the team. This ticket-person "affinity" may or may not be made explicit (via a label or some other categorization). This means that naively using our team velocity could lead us to incorrect forecasts. In such an arrangement we might get better results if we instead use the velocity of individuals (or groups of similarly shaped specialists).

This would complicate our model significantly, so it may or may not be worth it.