Is there a best practice for tracking feature development in a single ticket?

[Kevin Sweeney]

Our current process: We have three parts to feature development; requirements, development, and testing. To track this work in JIRA we use 3 individual story tickets. When the requirement story is done we close that ticket and start the development ticket, and when complete we move on to testing... a simple process that works fairly well.  In addition, each story (req's, dev, test, ) is created so it can complete within a sprint. End result is that feature development can take 3 sprints and along the way we're able to close those story tickets and take credit for the points completed. 

What I'm exploring:  I'm interested in figuring out a process to track Feature development, that includes all the sequential steps (req's, dev, test) in a single JIRA ticket. Ultimately, I'm curious if it's more efficient. 

Why: Reason for this possible change is that each step of our current process generates questions, new comments, screen shots, etc. So by the time it gets to testing the QA Engineer has to look through the past Requirements and Development stories to get history, updates, Q&A, etc. In my mind, it could be more efficient if engineers can work from a single ticket where they can see all the comments and changes. Looking through past tickets (although all related to the same feature) seems like a lot of context switching. 

Here's where this gets tricky: I can't use the Epic-Story hierarchy. Our Epics are reserved for high-level (ie. 4-6 sprints) features. Meaning an Epic will have 10 +/- of these lower-level features, and it's these low-level features I'm interested in tracking in a single ticket.

From what I can tell, the Story-subtask hierarchy may be an option. But I don't know how to take credit for the sub-task points completed in a sprint. 

Question: Does anyone have a process that works using a single JIRA ticket to track sequential steps? 

Thanks

[Danut M _StonikByte_]

Hi @Kevin Sweeney,

Welcome to the Atlassian Community.

Yes, it is possible to do this in a single ticket: a Story that represents that functionality. All you need to do is create a workflow in Jira that moves that Story through these statuses/stages: New > Req > Dev > Testing > Done. Also, the Scrum board should be modified to have these columns.

- New - is the default status, after the issues was just added

- Req - means the story is under requirements clarification (someone is working on its definition, mockups, acceptance criteria, etc.) - Usually this process should happen before the story is added in sprint (by prouict owner or product manager). The team should introduce it into the sprint after the story is clearly defined and can estimate and commit to its development (during sprint planning meeting).

- Dev - means that a developer works on it. When done, he/she moves it to Testing and makes the tester aware

- Testing - means that it is under testing, and if bugs are found it is moved back to Dev for those bugs to be fixed

Development, testing and bug fixing should all happen within the same sprint. So you should be careful about sizing stories so that they are fully completed (development + testing + bug fixing) in one sprint. This way you avoid "waterfall" and you will have the story completed and the end of the sprint so the team can demonstrate it in the sprint review/demo meeting - so a pretty clean agile process.

If a feature is too large to be fully developed in a single sprint, you should break it into several smaller stories (and possibly group them under an epic that represents the feature). There may be cases where a story is still large for a sprint, but that's it - you develop it over 2 sprints, but this should be just an exception from the rule.

Danut.

[Matteo Vecchiato]

Hi @Kevin Sweeney ,

Welcome to Atlassian community.

Interesting question and it is usual find this situation in Agile projects.

In my opinion, if the story usual duration is more than 1 sprint (3 sprints in your case) and differents teams are involved, it is not recommended to centralize all in one ticket with subtasks.

Sub-tasks are part of the story and if you need to move the sub-task to the next sprint, you have to move el the entire story; this cause losing the real situation and the metrics were distorted.

I suggest to create different story types and relate them with links.

A similar approach was described in this article 

I hope it helps