JIRA Issue to span multiple GreenHopper sprints?

[Tudor Hofnar]

For example, I have a user story that has both QA sub tasks and development sub tasks. Now we know its a huge story and will take 2 sprints to full finish it. So the dev sub task will be done in the first sprint and the qa tasks will be done in the second sprint. Is this possible?

Basically, how can I have one issue appear in 1+ sprints in GreenHopper? That way it can help with planning as well as its hours can be seen in both sprints?

Thanks for any help!

[Lee Correll · Accepted solution]

I don't think so.

Subtasks, in agile, are supposed to be finished in the iteration in which the main task is completed. Whether they are is a different story... but that's the reason you can't prioritize a subtask outside of it's parent task, for example.

What you can do is convert the subtask to a task - they'll be linked, but no longer subtasks.

Since you're using OnDemand, any plugins out there that might be of benefit won't help either. :(

[Tudor Hofnar]

Thanks! Is it possible to make a task rather than a sub-task span over 2 sprints?

[Lee Correll]

In other words, have it show up in 2 sprints? No. That's also an agile thing - tasks are supposed to be completable within the iteration/sprint timeframe.

Have you looked at either epics (some places call them themes) - or have you considered cloning your issues and then modifying them so that the tasks are better defined within the sprints? JIRA will keep track of the cloning / linking part.

[Tudor Hofnar]

I thought about duplicating the issues to achieve this but wasn't too sure if they were linked. I will give cloning and linking the issues a try to see what I can get working. Basically the reason I am asking this is because for example we get a User Story which has a few stages Design, Code, Test, Deliver.

Usually we complete the Design phase in the sprint before it is actually coded. So in that case I wanted the User Story to be visible in both sprints but the Design sub task would be completed in the first sprint while the Code, Test, Deliver sub tasks would be completed in the second sprint. Does that make sense?

Having the sub tasks under the User Story umbrella would make it easier for planning from the Business Analyst point of view while the team leads/devs/qa would deal with the creation of the sub tasks. Do you think it would be best to split up the 4 stages into separate tasks and link them?

Thanks for the help btw :)

[adelucca]

I'm running into the same issues - we might have an Action that involves mutliple tasks, that can happen in different sprints.

I want to:
a) quick view the whole story and tasks
b) assign tasks to different sprints
c) keep notifiying the multiple parties involved when they can start working on their task, or after done, update them of any changes that a related task has suffered.

Seems to me "linking" tasks can achieve b) & c), but
1) involves a manual process of actually linking each to the related one (which seems to be facilitated if you create a master/sub-task scheme and then convert the subs into tasks themselves).
2) intuitive visualization on the Agile board while planning

I've looked into using Epics but it they seem to behave same as tasks/subtasks (i.e. not allowing tasks in Epic to be assigned to different Sprints). For what I've researched this seems to be b/c they (forcefully) inherit the "Sprint" field from their parent. Unless I'm missing something?

Please help :-/

[Tudor Hofnar]

I'm not too sure, to me Epics don't meet the criteria at all. Its very difficult to tell what the Epic is when looking at the sub task of the Epic. Unless you click it and open the info panel on the right side. Especially on the 'Work' tab of Greenhopper Epics seem kind of useless to me. Not sure if there is anyting we can to make issues stretch over multiple sprints. The response that I've gotten before seems to lean towards the fact that an issue should be completable within 1 sprint as that is a principle of agile. But what about a Functional Design? Thats usually done a sprint before it is in development so it would be nice to have the general user story go over 2 sprints, where in the first one the FD is done and code/test is done in the second sprint. I have no idea if this ability is coming so I can't be of much help :(

[JDorman]

zombie thread... but how did you guys end up resolving this? Using JIRA differently? Ditching JIRA for something else? Changing workflow? I'm having trouble understanding how a User Story in Agile methodology could NOT have tasks that span multiple sprints. Discovery -> Solution -> Design -> Implementation -> QA ... each depends on the previous tasks, unless theres a fundamental piece I'm missing.

[Lee Correll]

Okay, so we'll have epics broken into a design task for one iteration/sprint; once the design is approved and estimated, an issue goes into the next (or whenever the stakeholder wants to put it in) iteration/sprint; QA is integrated into our workflow process; deployment is separate

[Lee Correll]

oops, clicked too fast. Deployment is separate; there may or may not be an issue related to it. The Epic task spans multiple sprints; the individual issue tasks are not supposed to.

[Lee Correll]

So we have a somewhat similar process; we recently have begun discussing workflow changes because of where the client fell into this process (similar to the agile question, "what's done mean?") For example, is the purpose of your testing above for internal QA - or is that User Acceptance Testing? What happens if it fails either (do you re-iterate/sprint, or is there a seperate issue, and how do you plan on tracking that?)

What we do - and it's not ideal, but it works - is we clone client issues and then move them to a software development project. That lets my folks put design notes / geek comments / etc. on a JIRA issue without cluttering up the client side issues (and generating tons of emails for the clients.) That also allows us to rearrange priorities and compensate for very rapid changes without the clients being aware/bothered by our internal processes.

We put the design parts on the client side, the coding and testing on the software development side, and the delivery part (after user testing) back on the client side.

[Tudor Hofnar]

Ah I see, we are doing a similar thing, except we're just plot-ing JIRA right now. Basically the QA I am referring to is internal. So our QA team wants to be able too track their defects under the specific user story, that way the manager can see where time was spent on each user story. Basically getting as deep into the hours spent as possible, how many coding, how many solving internal defects etc.

Our external defects come in from Zendesk into another project and the plan is to duplicate them into the Development project as you are doing. That way the customer is not flooded with internal emails.

I will give linking issues a try to see where I can get with that, but thanks again for all the help! You've helped me understand my problem a bit more if that makes sense haha.