Three Sprints with One Deployment

Jim Gentile

I'm using JIRA to track stories for this project.  We have three sprints and one deployment.  We use three status' with the stories: To Do, In Progress, QA, Done.

Historically, the company will change the name of the assignee based on the task.  Once development is complete the story is marked as Done.

There are lots of tracking issues with this process.  A solution is to create subtasks for the stories based on the task that needs to be completed.  Here is a list:

Discovery

Test Plan

Dev - Code Configuration

Dev - Test Class (if code)

Dev - Unit Test

Dev - Source Control

Dev - Code Review

Deploy to QA

QA Testing (Test & Regression)

Deploy to UAT

UAT

UAT Sign off

Test Package for Production

Production Deployment

Smoke Testing

However, all of these tasks after "QA Testing" will span the three sprints.  

With open tasks, I presume we would have to keep the story open and move it to the next sprint (4).  However, this would impact velocity.

What are the recommendations from the community to track all tasks that need to be completed with a story, when those tasks will not finish within the original sprint?

Should there be a Spike story for discovery; then a story for development; then a story for UAT and Production deployment?

Bill Sheboy

Hi @Jim Gentile  -- Welcome to the Atlassian Community!

You seem to be asking more of a process question than a JIRA tooling one.  JIRA is just a tool to help manage a team's work.

The team you describe is using high-level, status values (e.g. In Progress) while the majority of process details are in the sub-tasks.  All of this work is spread over 3-4 sprints from start to end for a request.  Thus the velocity measures you have today are not helping because they do not include the work capacity from the earlier sprints.

You could consider several options to help in an agile manner, a couple of which are:

1. Do work in smaller chunks, reduce your work in progress (WIP), and finish the smaller items in one sprint.  That would be more aligned with Scrum practices.
2. Or, accept that this is how you work and consider instead using Kanban methods.  There would be no need to carry over work sprint to sprint as it would flow with one process.  And, you could start gathering information about how long work takes to complete, the required capacity, and identify areas to improve.

Please consider discussing this with the team and coaches on how to proceed.

Best regards,

Bill