Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

What to do about fast and easy requests?

In addition to large projects and backend work, my team receives a large amount of quick content changes for our website. The expectation is that these can be done in less than 20 minutes and we have a dedicated developer that makes these changes. Sometimes these are made and approved before EOB the same day. 

We are currently discussing the best practices for dealing with these type of tickets in Jira. Our main thought is we cannot put these into normal sprint planning because the expectation across our org is that these are very quick changes and should not take weeks to get to. Waiting until the next sprint is even too long. The different options discussed are as follows:

  1. Creating an always open sprint that these can live in and using versions to align the due date with the end of the sprint current sprint.
  2. Leaving them in the backlog to be completed and including manual search filters to include that developer's work in sprint and EOQ reporting.
  3. Continually add those tickets to the current sprint and complete are they are done.

Are there any best practices around fast and easy tickets in Jira and in Agile?

1 answer

0 votes

We wrestle with this as well. We considered using Kanban board for the many, similar-sized pieces of work and a Scrum board for the other planned work. At the moment we are considering having a tracking task each sprint that is linked to all the small pieces of work.

@Matt Doar__ LinkedIn , thank you very much for the response! Do you meant just creating an additional board to track the progress of these tickets? Just want to make sure I understand what you mean.

After I posted that, I came across another potential solution which is using parallel sprints. The idea is that we would treat those that do content uploads and fast tickets as a different team, and we would just throw those tickets into their own sprint.

We could use a more loose methodology on that sprint because we would not really have to worry about how many of those tickets we get to, or individual tickets taking too long. Then, we could really focus on solid methodology for the development and roadmap projects in their own sprint. Have you looking into that or tried that in the past?

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you