Hi all - I’m Head of Delivery at a small company and I’m looking for advice on where to tighten up our Jira configuration and team process without burying a small team in overhead. Background on our team and setup is at the bottom. The problem The team is used to working together informally (Slack requests, picking things up as they come). That works well for collaboration, but our sprints rarely finish what we planned (typically around 60-70% of committed points) and we’re regularly missing roadmap dates. What I’m seeing: * Scope added mid-sprint: New work gets added to the current sprint, so scope only goes up and planned work rolls over. This comes from a few places:* Developers find additional work once they start on a story and raise new tickets for themselves to work alongside it * QA raises bugs and adds them to the current sprint. Developers switch to fixing those, so other planned work doesn’t get done * Support tickets from our JSM space are handled by the same back-end engineers, which also pulls time away from sprint work * Work handed over before it’s ready: Work moves from architecture to design to development (or some combination), but upstream work isn’t always finished when it reaches the next step, so it gets blocked. * Epic dates set before scoping: Epics get target dates before all the work is identified. New work then turns up during delivery and we keep revising dates, rather than catching it up front. I’ve considered a triage process or checklist, but I’m worried it adds overhead and becomes a bottleneck for a team that’s used to just sorting things out together. My questions * For small teams used to working informally, how have you balanced formalising work in Jira (process, automation) with letting the team keep working the way they do? * How do you handle unplanned work (new bugs, discovered work, support) without it derailing the sprint? Do you hold capacity back for it, and if so how much? * What’s the lightest-weight way you’ve found to make sure epics are scoped enough before committing to a date? * How do you keep an eye on whether releases are on track and of good quality, without adding a lot of reporting overhead for the team? * Have you used in Jira tools/configuration or automation, Marketplace apps, etc. that have helped with some of this? Team and company background * Small company doing professional services work alongside a SaaS product * I’m Head of Delivery, working with engineering and design to keep delivery on track (internal roadmap items and customer commitments) * Team in Jira: CTO, Head of Delivery, 1 architect, 3 back-end engineers, 1 front-end engineer, 1 QA, 2 designers * Engineers cover new delivery, bug fixes and ongoing support for existing customers * Sprint length: 2 weeks Our Atlassian setup * Jira Cloud, two spaces:* Delivery space: all development and design work for professional services, customer releases and the SaaS product * Design space: non-development design work (ex: website, presentations, marketing materials), used only by the two designers * Jira Service Management: one support space for customer issues raised by email, mostly handled by the back-end engineers * Confluence Cloud for documentation * Figma integration in Jira * A custom-built app that syncs both ways with Jira for planning and reporting:* Calculates sprint capacity in story points from our Outlook out-of-office calendar * Compares sprint plans against that capacity * Forecasts roadmap dates from upcoming capacity, sets them in Jira and flags when a date can’t be hit (with a suggested new date) Thanks in advance for any advice!

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira process and setup for small teams (<10 people)

Aimee Roddick (Walter)

Hi all -

I’m Head of Delivery at a small company and I’m looking for advice on where to tighten up our Jira configuration and team process without burying a small team in overhead. Background on our team and setup is at the bottom.

The problem

The team is used to working together informally (Slack requests, picking things up as they come). That works well for collaboration, but our sprints rarely finish what we planned (typically around 60-70% of committed points) and we’re regularly missing roadmap dates.

What I’m seeing:

Scope added mid-sprint: New work gets added to the current sprint, so scope only goes up and planned work rolls over. This comes from a few places:
- Developers find additional work once they start on a story and raise new tickets for themselves to work alongside it
- QA raises bugs and adds them to the current sprint. Developers switch to fixing those, so other planned work doesn’t get done
- Support tickets from our JSM space are handled by the same back-end engineers, which also pulls time away from sprint work
Work handed over before it’s ready: Work moves from architecture to design to development (or some combination), but upstream work isn’t always finished when it reaches the next step, so it gets blocked.
Epic dates set before scoping: Epics get target dates before all the work is identified. New work then turns up during delivery and we keep revising dates, rather than catching it up front. I’ve considered a triage process or checklist, but I’m worried it adds overhead and becomes a bottleneck for a team that’s used to just sorting things out together.

My questions

For small teams used to working informally, how have you balanced formalising work in Jira (process, automation) with letting the team keep working the way they do?
How do you handle unplanned work (new bugs, discovered work, support) without it derailing the sprint? Do you hold capacity back for it, and if so how much?
What’s the lightest-weight way you’ve found to make sure epics are scoped enough before committing to a date?
How do you keep an eye on whether releases are on track and of good quality, without adding a lot of reporting overhead for the team?
Have you used in Jira tools/configuration or automation, Marketplace apps, etc. that have helped with some of this?

Team and company background

Small company doing professional services work alongside a SaaS product
I’m Head of Delivery, working with engineering and design to keep delivery on track (internal roadmap items and customer commitments)
Team in Jira: CTO, Head of Delivery, 1 architect, 3 back-end engineers, 1 front-end engineer, 1 QA, 2 designers
Engineers cover new delivery, bug fixes and ongoing support for existing customers
Sprint length: 2 weeks

Our Atlassian setup

Jira Cloud, two spaces:
- Delivery space: all development and design work for professional services, customer releases and the SaaS product
- Design space: non-development design work (ex: website, presentations, marketing materials), used only by the two designers
Jira Service Management: one support space for customer issues raised by email, mostly handled by the back-end engineers
Confluence Cloud for documentation
Figma integration in Jira
A custom-built app that syncs both ways with Jira for planning and reporting:
- Calculates sprint capacity in story points from our Outlook out-of-office calendar
- Compares sprint plans against that capacity
- Forecasts roadmap dates from upcoming capacity, sets them in Jira and flags when a date can’t be hit (with a suggested new date)

Thanks in advance for any advice!

Accepted answers

Bartosz Stankiewicz

Hi Aimee, on your follow-up about the Definition of Ready: yes, small teams do keep it in Jira, and it is not much overhead if it stays tiny and lives on the ticket. What kills it is a long list on a wiki page that nobody opens at handover. Arek's "Ready for Development" status with a validator is a good start, but a field validator can't tell whether design was reviewed or upstream work is actually finished, which is your handover problem.

Disclosure: I build Checklist Flow, a Jira app made for this. In your setup it would work like this:

(1) Write your DoR once as 4 to 6 yes/no items ("Architecture agreed", "Designs linked in Figma", "Acceptance criteria agreed with QA").

(2) The list is added automatically to every new Story in the Delivery space, so nobody has to remember it.

(3) Mark the must-haves as Required and put the validator on the move into Ready for Development. Jira blocks the transition and shows which items are still open, so half-finished work stops arriving at the next step.

(4) A dashboard gadget and JQL show which tickets are not Ready yet, which also helps with your epic dates: unscoped stories show up before you commit.

It is free for teams up to 10 users, so you could trial it for two sprints at no cost. After that, delete any item nobody ever fails so it stays light.

All comments

Arkadiusz Wroblewski

Hello @Aimee Roddick (Walter)

With your current 60–70% completion rate, you should focus on understanding where the remaining capacity goes and not introducing more tools or processes.

few suggestions:

Set aside some sprint capacity for unplanned work and JSM requests.
Use Jira's Sprint Report to monitor scope changes.
Implement a simple Definition of Ready to minimize handoff delays.
Review dependencies and risks prior to committing to timelines for Epics.
Track committed versus completed work to enhance forecasting accuracy.

Besides that ? Kind of taste thing.

Best,

Arek🤠🧙‍♂️

Aimee Roddick (Walter)

Thank you! That's what we're starting to do, and definitely setting setting aside the capacity and using reports to monitor changes.

3. For the Definition of Ready - We do have this, but often find that it's not being followed. Do you see small organisations/teams have this within Jira? Or is that often too much overhead?

4. We're trying to do this, but we don't have a clear triage process for new work, and it's often that it's getting started without the entire team being aware. Do you recommend anything here within Jira?

5. We are tracking and reporting on this, and we understand where things are coming from. Trying to understand how much we should be trying to build, automate, etc. within Jira without it being too much overhead for the team.

Arkadiusz Wroblewski

@Aimee Roddick (Walter)

Test these changes for 2–3 sprints. The goal is to reinforce your existing process, not add more overhead.

Add a "Ready for Development" status and enforce critical fields using workflow validators where supported.
Review new work daily before adding it to a sprint.
When urgent work enters a sprint, agree on what gets deprioritized.
Automation: Notify the team about untriaged work or scope changes.

For a small Team, don´t overdo processes.

Ahmed Fiaz

Hi Aimee, two of your problems are really the same one: work that appears after the plan is set. Here's a lightweight way to keep it visible without adding a triage step.

Discovered work: attach it, don't add it. When a developer finds more work inside a story, have them add it as a subtask of that story instead of a new ticket in the sprint. A subtask lands in the same sprint as its parent, the sprint keeps the same list of stories you committed to, and in retro you can see exactly which stories grew. If the new work could ship on its own, make it a story under the same epic and put it in the backlog for next sprint.

Epic dates: date the tree, not the epic. Before an epic gets a target date, look at its whole breakdown (epic, then stories, then subtasks) and check every story has actually been split. A story with no subtasks and no estimate is unscoped, and that's usually where the later surprises come from. A simple rule like "no date until every story under the epic has been broken down" is much lighter than a triage meeting.

One catch: the epic's own view only shows its direct children, so to see stories and their subtasks together you'd need Plans (on Premium) or a tree view. Disclosure: I make Cascade for Jira, a free Chrome extension that shows that tree, so that's the one I use.

Project Commander

Hi Aimee, on holding capacity back: yes, but size it from your own sprints. For the last five or six, add up the points of issues created after each sprint started, plus the support tickets the back-end engineers picked up. That average is your reserve. At 60-70% completion I'd expect most of the missing third to be there, and if so the team isn't under-delivering; the plan is counting time that was never free.

Your app already works out capacity from Outlook, so take the reserve off there before it compares the plan, and the forecast dates absorb it too.

On epics, lighter than a checklist: an epic with any story still unestimated gets a date range, not a date. No meeting needed, and customers hear early that it can move.

Disclosure: I build a Jira app called Project Commander, on the Atlassian Marketplace. Its Retrospective tab shows each closed sprint as delivered against planned, with what was carried over and what was added mid-sprint, which is the history the reserve comes from. You've built most of the rest yourselves, so it's only worth a look if yours doesn't keep that split.

Maxime Ragionieri (Clearlane)

Hi Aimee, I'm with Clearlane, we build Jira dashboard gadgets. On your last question, one thing that hasn't come up: you can follow a release without any report. A dashboard with two native gadgets is enough: Filter Results on fixVersion = "X" AND statusCategory != Done shows what's left, and the Created vs. Resolved Chart on fixVersion = "X" AND type = Bug shows whether bugs close faster than they open. The team works as usual, and you read it in ten seconds.

If you'd like the sprint on that same dashboard, our Clearlane Sprint Burndown gadget lists the work added or removed mid-sprint, which seems to be where your missing third goes: https://marketplace.atlassian.com/apps/347369830

Bartosz Stankiewicz

Disclosure: I build Checklist Flow, a Jira app made for this. In your setup it would work like this:

(1) Write your DoR once as 4 to 6 yes/no items ("Architecture agreed", "Designs linked in Figma", "Acceptance criteria agreed with QA").

(2) The list is added automatically to every new Story in the Delivery space, so nobody has to remember it.

(4) A dashboard gadget and JQL show which tickets are not Ready yet, which also helps with your epic dates: unscoped stories show up before you commit.

It is free for teams up to 10 users, so you could trial it for two sprints at no cost. After that, delete any item nobody ever fails so it stays light.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-cloud

process

process-improvement

process-management