How does Scrum work when you can't add subtasks to sprints?

[Deleted user]

It's very clear from the number of questions raised that Atlassian Just Will Not allow the separation of a story into multiple Sprints. Because that's just not how Scrum works.

So rather than argue in the existing tickets or raise yet another ticket arguing the point, I want to know how the Atlassian Way is supposed to work.

Background:

Our team is multidisciplinary. We have BAs, Architects, Coders, Testers and Network Admins. Our workflow takes a ticket through the process of analysis, design, build, QA and release. Currently we create an Issue and move it through that process. But I'd like to move to planning a Sprint using JIRA Agile.

We really don't want to create a ticket for requirements gathering on a BA workflow and another ticket for architecture on another workflow and another ticket for build on another workflow and another for test on another workflow and a final ticket for release on yet another workflow. So I thought about it and decided that we could just include subtasks on each ticket. That way we can include the architecture planning in one sprint and then the build in the next and the test in the next.

But I'm not allowed to add sub tasks to a sprint. And if I add the issue to a sprint and only work on part of it, then the sprint is too big at the start and fails at the end.

So please tell me: how does Atlassian expect me to work? Does every story become an Epic just so I can get an issue assigned?

If we have to complete entire issues (stories) in a single sprint, we'll have the architects working for a few days, then the coders, then the testers with a lot of downtime for each group.

It's clear from Atlassian's responses that every single requester is wrong about how it should work. So please ... tell me how it should work.

[Steven Larsen]

I'm a relative newbie when it comes to agile. I've been a developer for more than 20 years so have been in the middle of the agile rise to fame. I've never been on a team that has implemented agile in any way the "experts" define it. Instead, it seems they all have their own flavor, picking and choosing the pieces they want to implement. And I've been told that is a good thing and what agile is all about (no defined set of processes you must follow from beginning to end). I don't recall any of them using actual software tools like JIRA to manage the sprints. They were more managed on spreadsheets and white boards.  Now I'm on a big project and a small team of developers and the overall code is tightly intertwined (so one feature can leverage code from another feature) and we are using JIRA. This is also my first time of actually setting up the epics and stories so the hands-on involvement with this process has brought to light a lot of questions. Mostly "why" questions, but questions, starting with the most fundamental: the differences between epics, stories and tasks.

And to the point that Requirements -> Development -> QA is somehow not agile is confusing to me.  If the goal of a sprint is to "deliver" something to the client by the end, then it only makes sense you would put the requirement in a back log, add it to your sprint, develop it, QA it (so you know it is ready for delivery), and deliver it. That may be more of a waterfall process, but it's a pretty standard process that I'm not sure how it would differ using agile. Are you suggesting that if you are agile, you're not developing and then QA'ing? Are they separate sprints? In fact, we have "Testing (Dev)", "Testing (UAT)" and "Staging" as part of our process. Should all of those be on a sprint board or are they separate steps/sprints, or what? I mean, we have to staged things before we push them into production and we'd like to track that and the "feature" (no matter how atomic in nature) is not complete until it is in production. So are we by definition waterfall and not agile because we need to do this ? Though I think every software project needs to do some resemblence of this.

Software development seems great for agile but at the same time, there are standard steps in the process of developing something which is being suggested here as not agile (at least that's how I'm reading it).  I'm quite confused. Sometimes it seems the whole point of agile ("to be nimble and not get caught up in the weeds"), becomes its own monster trying to properly design epics and stories that must "fit" in sprints, etc.  You end up spending a wealth of valuable time "setting up" the agile environement than you do actually developing. Great for project managers I guess, but frustrating for a developer.

I guess for me, I don't understand why on a board it matters whether the item on the board is a "story", a "task", or some other "issue", I really don't.  In the end, they are all labels ("tasks", "issues", whatever), so who cares? The linking and hiearchy between epic, story, and tasks is where the rubber meets the road and allows those awesome reports and fancy graphs.  So why do we care so much that in a sprint it "MUST" be a story?

It's funny that in one respect that the definition of "agile" (able to move quickly and easily), follows a set of processes that, defined by some as "do it the way it makes sense for you", and then others who say "you're not doing agile if you're doing it that way". In the end, agile to me has become a big "huh?".

[Nic Brough -Adaptavist-]

>I don't understand why on a board it matters whether the item on the board is a "story", a "task", or some other "issue",

Same here, I treat them all the same when it comes to the Scrum thing.  The type of issue can be useful for other reasons, and have different fields and workflows, but I estimate, calculate, split, move, progress everything at that level as though it's a story.  (Sub-tasks are shards of a story, so they go into the sprint with their parent.  If they're not really part of a story, I convert them up a level)

[Rahul Aich [Nagra]]

Hi

Let me highlight to you a serious flaw i see. You are defining that a software development lifecycle should follow a certain sequence i.e. requirement gathering-> Development -> QA and so on. This in itself is  a waterfall methodology where you define a sequence of steps and one MUST follow the other. This is not agile.

In agile, you agree with you customer what you want to deliver in a sprint and deliver it from start to end. In your case if your stories are too big that it cant be done in a single sprint, then might be a good idea to break the user stories into small implementable features. 

You then decide that in a sprint you are going to complete the entire feature.

If i were you, i would simply break down my user-stories into smaller features and use them for estimation. Once the sprint starts i may then break them into sub-tasks for say QA, release or analysis (if you so wish).

I think this is the reason you may have been struggling to find a solution with jira-agile as jira-agile was not designed in the first place to support waterfall methodology.

Rahul

[Nic Brough -Adaptavist-]

That is pretty much what I would have said too. 

You've got a non-Agile process that you're trying to be Agile with.   JIRA Core is not particularly Agile, so it can easily fit your process.  JIRA Software is very much aimed at being Agile, so it's less able to fit your process.

There's a lot of good in Agile, but you have to embrace it, and that means changing your processes to be Agile.  Whether you choose Scrum or Kanban, or something between the two is one choice.  If you're going to stick with the overall process you've described to us here, then I'd look at

• Accepting that stories are going to span sprints (makes the numbers a bit crummy, but as your process isn't Agile, you're not that worried about it anyway)
• Learning to break up stories better into ones you can fit into sprints properly
• Extending your sprint length so that your stories can fit (I wouldn't recommend going over 4 week sprints for most people, but I have seen 8 week sprints work!)
• Go more Kanban - forget the sprint planning, because your process isn't Agile enough to do it.  Kanban works better with waterfall because it's a lovely simple "stuff that needs doing" approach, which can be planned any way you want as long as the priorities are clear.

[Troy Spetz]

We use JIRA 7.12 server version.

We use Epics for product features which may span 1+ sprints or even 1+ releases. As the Epic is not assignable to a sprint and does not have to be assigned a FixVersion (i.e. remains Unscheduled), it is the only 'grouping method' within JIRA which can span multiple sprints or FixVersions.

Issues (i.e. new feature, improvement, tech debt, defect or chore) are assigned to a sprint -- if they can be completed within the sprint. If they are too large for a single sprint, then they are split into multiple issues which are sequentially 'blocked by'.

We only use sub-tasks for work which can be done in parallel (under a parent issue). Only after all of the sub-tasks are completed does the parent issue become testable (as this is where the Developer and Tester Story Points are assigned).

[Pedro Ferreira Caetano Marques]

!