What to do about fast and easy requests?

Question

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:

* 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.
* Leaving them in the backlog to be completed and including manual search filters to include that developer's work in sprint and EOQ reporting.
* 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?

Chris deMontmollin_9o6bq8 · Answer

@Matt Doar , 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?

Matt Doar_tzgiej · Answer

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.