Moving Sprint-completed Items to a 2nd Sprint

[ESamlin]

Hi -- I'd love some advice from fellow Jira users on a challenge I'm facing at my organization.

Our setup: we have multiple client engineering teams (e.g., iOS, Android, tvOS, etc), each with its own Jira project and scrum board (which uses just a simple query like "project = IOS"). For reasons that I won't get into here -- and I know is not agile best practice -- our sprint board considers work complete when the code is merged and testable. QA/stakeholder review/app store submission are subsequent steps in the workflow that occur after the sprint ends and are all mapped to the 'Done' board column. (Let's assume this is not changeable right now.)

We have another "Analytics" team that's responsible for creating new Analytics requirements (their own issues in their own Jira project) as well as tracking clients' implementation of those specifications (issues that live in the respective client projects). Their board query reflects this mix (e.g., "project = Analytics OR project in (<clients>) and component = Analytics").

The challenge: When the client sprint closes -- ie., code is merged and we're in the QA/release phase -- those code-merged issues obviously disappear from the client board (given that they're considered "done" per above). The Analytics team then grabs the relevant issues and moves them into their own "Analytics Sprint" to track their own QA/review efforts. The Analytics team feels strongly that they should see their QA/validation work in their own sprint view, even though they're not doing any velocity tracking, and are reluctant to use dashboards/filters instead (they want to see all of their work in one consolidated list vs splitting out requirements work and QA/validation work). This feels a bit unorthodox/gross to me:

• The Analytics Sprints show up on the client boards, which can be confusing for the teams, and cause unintended side effects

• Other cross-functional teams in the org. don't use this approach -- they either know how to check status by looking at client teams' boards or they create filters/dashboards

• It feels incorrect that issues completed by client engineers end up in a different team's sprint, albeit after the initial client sprint ended

Are there any other potential problems with this current approach that I'm missing? Should I just stick with this current process and leave well enough alone, or is there a better way for all teams involved? Any advice is welcome -- thank you!

[Derek Fields _RightStar_ · Accepted solution]

From reading your description, the only "problem" that I see is that when the story moves into the Analytics Sprint, that sprint shows up on client boards because they involve stories that are mapped to the client board. 

In "ideal" Agile environment, a team would be capable of handling a story from start to finish. The story wouldn't be handed off from one team to another. However, in your configuration, that is what is happening. A story first belongs to the client development team. When it is completed and merged into the main trunk, the ownership of the story passes to Analytics.

If I were in the Analytics team, I would want to see stories for which I am responsible on my board. That said, I wonder whether they are actually working in Sprints or whether a Kanban board would be sufficient for them to track their stories. If they need to work in Sprints, you could exclude those stories from the client board by extending your board filter to exclude stories that are in statuses that belong to Analytics.

Let me know if that helps.

[ESamlin]

Thanks Derek! I think this was a good idea I hadn't considered -- finding a way to filter out those Analytics tickets from the client boards when in certain statuses. Unfortunately for me, the teams share similar workflows throughout QA and stakeholder view, so it wasn't a straightforward query update, but I think I found something that works.