Thursday, issue-log review. Twelve open rows, three of them red. The vendor’s API is two weeks late. The payments migration surfaced a data-quality problem nobody saw in testing. A senior engineer has been pulled onto a production incident. Every row has an owner, a priority and a due date. Then someone from the business asks the only question they came for: “So are we still on for the 14th?”
The issue log doesn’t have that column.
What an issue log is for
An issue log, sometimes called an issue register, records problems that have already happened. A typical issue log template carries an ID, a description, the date raised, an owner, a priority, a due date, a status and a resolution. It is the I in a RAID log, and the distinction from its neighbour matters: a risk is something that might happen; an issue is a risk that did.
The project issue log is good at what it was built for. It makes sure every problem has a name next to it, nothing gets lost between meetings, and someone is chasing the fix. That is ownership and follow-through, and teams that keep one well are better for it.
The column it doesn’t have
Look at what the columns actually say about the release. Priority is ordinal: “high” does not tell you whether the problem costs two days or twelve. The due date is when the issue should be resolved, not what it does to the date you committed to. And the review runs weekly, while the release date moves whenever the work does.
Rows also interact. Three medium issues that land on the same chain of work can cost more than one high issue sitting off to the side. A list sorted by priority cannot show that. So the review ends with every row owned, and the one question the business asked still unanswered.
Every open issue is one of three things
When the team committed to the 14th, that confidence vote was expert engineering judgment. They weighed how big the items really were, which throughput window reflected how they work, and who would be on the release. A confidence vote is a snapshot of that judgment. What happens to the date afterwards is post-commitment erosion, and the issue log is where most of it gets written down first.
Whatever the description says, almost every logged issue lands in Jira as one of the three things that erode a committed release date:
- Scope. The data-quality problem becomes five fix and rework tickets on the Fix Version after the vote.
- Dependencies. The late vendor API becomes a blocking link at the head of a chain of work, surfaced after the plan was agreed.
- Capacity. The engineer on the incident is a person the release no longer has for a week.
That is the same gap the risk register has one step earlier: it scores likelihood and impact, but never says how many days. The issue log inherits the problem at the moment the risk becomes real. Like the rest of the RAID log, the register is fine; the refresh rate isn’t.
Add the number to the review
The fix is not a new column someone fills in by hand. It is one number read at every review: the gap, in days, between the committed date and the forecast at the confidence the team committed at.
An illustration, not customer data. The team committed to 14 November at 85% confidence. Before this week’s review, the 85% forecast sat at 12 November: two days of headroom. Then the three red rows land in Jira. The vendor slip adds a blocking chain, the payments fix adds five tickets, and the engineer is out for a week. The 85% forecast is now 21 November, seven days past the commitment. The 50% line is 13 November, so the release reads attention, not yet at risk.
Now the review has something to decide. Resolve the vendor dependency first because it sits on the longest chain? Move two Could-haves out of the Fix Version? Renegotiate the date with the business today, while there are still options? The team still owns every one of those calls, and every assumption behind the forecast. What changes is that they make them before the slip, not after it.
Where Advanced Release Planning fits
Advanced Release Planning for Jira does not store or replace your issue log. Keep it where your team keeps it. The app reads what the open issues turn into in Jira: work on the Fix Version, issue links, and capacity changes such as PTO, public holidays and reallocation. It runs Monte Carlo simulation over the team’s actual throughput and keeps the committed date and its confidence band (50%, 85%, 95%) current as scope, dependencies and capacity move. The team sets the assumptions; the app does the arithmetic at scale and keeps it live. Release status reads on-track at or above P85, attention between P50 and P85, and at-risk below P50.
For the step-by-step mapping of issue-log entries to what the forecast reads, see the issue log reference doc.
Key takeaways
- An issue log owns the fix. It does not say what an open issue costs the committed date.
- Priority is ordinal and the review is periodic; the release date moves daily.
- Almost every issue lands in Jira as scope, a dependency or a capacity change.
- Read the gap in days at the committed confidence at every review, and renegotiate before the slip.
FAQ
What is an issue log?
A record of problems that have already occurred on a project, each with an owner, a priority, a due date and a status, reviewed until the problem is resolved.
What is the difference between an issue log and a risk register?
A risk register tracks things that might happen. An issue log tracks things that have happened. When a risk materialises, it moves from the register to the log.
What should an issue log template include?
The usual columns are ID, description, date raised, owner, priority, due date, status and resolution. For a release, add one more reading at each review: the gap in days between the committed date and the forecast at the committed confidence level.
Keep your issue log. Add the number it’s missing. See the committed date and its live confidence band in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.