How can I view sub tasks AND linked defects in swimlanes for stories on the Kanban board?

[SamanthaB]

For each sprint my team complete, we create stories and assign sub tasks to each before they are accepted into sprint. During testing, any defects we find for a story or with the ACs are then linked back to the original story. 

We use the swimlanes on the Kanban Board so that we can also view the task progress for each story. However, we would also like to view the defects related to each story when expanding the swimlane view. At the moment, defects related to a story appear in the 'Other issues' section which is not very useful when we are trying to discuss the state of each story during standups. Without maintaining a visual board outside of Jira, we cannot see what defects are preventing our stories from being closed by the PO. 

I have done some cursory google searches to try and find out if it is possible to see both defects AND tasks related to a story in the swimlanes. I found this answer which suggested that I could set the swimlane option to 'Queries': https://answers.atlassian.com/questions/177329 but I am not sure what JQL to use to see both linked defects AND sub tasks.  

I have multiple projects using the JIRA Kanban boards with swimlanes enabled. The 'base swimlanes on' option is set stories. Each sprint we complete can contain multiple epics so we cannot use the epics setting. The assigness option does not provide the information I need and we do not use the Kanban board for multipl projects. 

Is there a way to see both linked defects and sub tasks for stories in the Kanban swimlanes? 

[Nic Brough -Adaptavist-]

You can't.

JQL returns a list of issues based on some criteria, but the JQL is not the issue.

The board is coded to display stories with their sub-tasks when you select "swimlane by story".    That's it.  Linked issues don't matter to the swimlane.  You can get them on the board if the filter is clever, but they won't land in a swimlane. 

This is by design - linked issues generally should NOT be represented as part of a story.  Because they're not part of it.  They have a relationship, yes, but they're not part of it.

The closest you'll get is swimlane by query - you'll be able to get to "issue x, its subtasks and linked issues", but it will be one swimlane query for each story you want to track this way.  It won't be flexible or dynamic, you'll have to create a swimlane query for every issue.  Even if you do this, you have another problem - you can link issues in many ways, it's directional and you can have multiple links, so you'd need to account for that.

The simple answer is "your defects are in the wrong place".  Raise them as sub-tasks on the stories instead, and it'll all work fine.  (Or, as a bit of a bodge if you can't do them as subtasks, raise subtasks that are then linked to one or more defects)

[SamanthaB]

Hi Nic,

As part of our agile process, we cannot close a story unless all defects raised against the acceptance criteria in the story are completed. It's not right for us to raise them as tasks against stories in order for them to appear in the swimlanes as they are not tasks to action, they are defects. I realise this may be as per design but this is not realistic as to how we use the stories and defects in a sprint. Is there any way this can be changed (a new feature perhaps or a JQL query we can set) so that we can see (everything) that is linked to a story and the see which column (progress) it is currently in? 

Thanks

Samantha

[Nic Brough -Adaptavist-]

Ok, this seems wrong to me:

>It's not right for us to raise them as tasks against stories ... as they are not tasks to action, they are defects.
If they are separate defects, then you don't need them in the swimlane.  They could be related to the issue, but they're not part of it.

If they need to be closed off before you can deal with the story, that's fine too, they should be in the swimlane, but that makes them part of the story, so they probably should be subtasks.

I think you need to make a firm decision about whether they're part of the story or not.

JIRA won't support your current half-way process, and I very much doubt that Atlassian will ever change the boards that far away from Agile standard processes.

[SamanthaB]

Hi Nic,

Our current process is that a story cannot be moved to awaiting approval (for a PO) until all linked P1/2 defects have been closed and all tasks are complete. This means that there is a need to be able to close a story if there are P3/P4 issues still linked also. Once the PO has performed their checks and accepts the new functionality, the story is then closed. 

We link the defects found with a new piece of work to the story itself so that it can be traced back. These are not tasks as they are reports of bugs to be fixed and not tasks to execute or make changes to the current requirements. 

It just seems odd to me that a task can be seen in the swimlanes for stories (very useful) but we cannot do this with bugs that are associated to a story. We link the bugs much like you would link a (sub)task to a story. I was hoping you had a clever way for me to do this but it looks like this may be a limitation of JIRA that I cannot customise multiple issue types to be assigned to a story and to appear in the swimlanes if stories are selected. 

Thanks

Samantha

[Nic Brough -Adaptavist-]

So, you're defining things that are part of the story as not being part of the story.  This isn't a limitation in the software, it's working logically.  If your bugs are genuinely part of the story, then treat them as such.  If they're not, then don't expect them to appear with the story.

[SamanthaB]

I think I can see what you are trying to say. For the time being, ignore my comments around P3/4 issues and just assume that a story cannot be set to Awaiting Approval and closed by the PO until all sub tasks assigned to the story are closed and all bugs assigned to the story are closed. 

Our workflow permissions prevent the closure of a story until all sub tasks are closed. These appear in the swimlanes. 

Our workflow permissions prevent the closure of a story until all linked bugs are closed. These do not appear in the swimlanes. This means the story has to be opened in full to observe the linked issues.

I realise that you can assign a subtask to a bug also (which I can see some uses for such as adding new development and testing tasks to that bug found) but there is no correlation between the story and the bugs which have been found when testing the story itself. Instead we have story tickets and bug tickets which are not linked in the same way as sub tasks. I could add a subtask to each bug raised and linked to a story, with the same name, but this would be unnecessary duplication. 

[Nic Brough -Adaptavist-]

So, why aren't the bugs logged as sub-tasks?  They belong to the stories from what you've just said.

[SamanthaB]

Because they are not sub tasks.

A bug is a record of a defect found in the new/existing code base. If the defect is found in the new code which is a result of completing story ACs, then it is linked to the story that caused the defect. A sub-task is an action to be taken by a scrum member in order to complete a story or a bug. 

If I was to create all defects relating to a story as a sub task on that story, then these would be tasks and not bugs and affect the reporting at the end of the sprint. This would also render the bug issue type, redundant if I were creating sub-tasks instead of bugs.

[Nic Brough -Adaptavist-]

But that contradicts what you're saying about them counting towards progress on the issue.  I think this needs to go back to making a solid decision about whether they're part of the story.  If they are, then make them sub-tasks.  If they're not, then links are a good way of indicating a relationship, but they're not part of the story, so they don't need to appear on the boards with the stories because they're not part of them.

[SamanthaB]

I do not understand how this contradicts what I have said throughout this post. 

A story is not complete until all sub-tasks and linked bugs are closed. So this decision has already been made. 

Bugs cannot be made into sub-tasks as they are bugs, not tasks. 

The bugs are linked to a story as there is no other way to link the bugs to a story to make them part of a story. 

[Nic Brough -Adaptavist-]

Yes, that's fine. 

But you then say you want see linked issues as part of the story.  But you don't because they're not part of the story.  Which one is it?

[SamanthaB]

All linked bugs and sub tasks are part of the story. And the story cannot be closed until the linked bugs and sub-tasks are closed. So if I can see linked sub-tasks on the swimlanes, I also want to be able to see linked bugs on the swimlanes as these need to be closed before the story can be closed. 

[motherg]

Hi Sam,

I think you're taking the sub-tasks bit too literally. As you stated earlier, your DoD states you cannot complete a ticket unless all the bugs against it are resolved (or I assume you decide that you can live with some bugs and they just got in to the backlog?). That's absolutely fair, it's for your team to decide after all.

We've created another sub-task issue type called "dev bug" for exactly the situation your discussing (although we use that or the Sub-Task issue - we're not that fussed now). If you do it this way you'd still be able to run reports that query for this specific type of issue and I'd imagine it wouldn't affect your reporting too much? 

We look at it (for better or for worse, but it works for us) as if there are two types of bug - production defects and development defects. If we find a dev defect we log it as the "dev bug" sub-task issue type mentioned earlier, if we find a bug in production we raise a production defect. IF we decide to ship something with "open" development bugs (we sometimes choose not to fix it due to the effort required vs is severity + having not metrics to see how often it occurs in the wild) we Convert to Issue, making them a Production Defect as they now are.

As an Agile Coach I'd really question what you're learning from the reports you have at the end of the sprint as well - sure, you may have raised a lot of development bugs, but what was the impact? For example, did it mean you couldn't finish the forecasted stories?

[Nic Brough -Adaptavist-]

But you said you don't want the linked issues to be part of the story. 

I'm sorry, we're going in circles here.  I can't work out if you want the linked issues to be part of the story or not.  If you do, then they should be sub-tasks.  If you don't, then you're fine as you are, but you won't see them in the swimlanes, because you've decided that they are not part of the story.

[Nic Brough -Adaptavist-]

p.s. that comment was a bit longer while I was typing, but @mother-goose has said a lot of what I was trying to type, and it's a better write up than I had.

[SamanthaB]

Hi mother-goose, 

Yes, this is the same sort of approach we use. Hence my comments around P3/P4 issues (we have an internal agreement that these are low risk and not related to the core ACs of a new story so we can close a story and push live with these issues and move them to the backlog) but I think this confused matters further. 

We already raise different defect types to if they come out of regression testing, functional testing of a story ACs or integration testing. Defects found on live are also flagged differently. 

The problem for me is, a story cannot be closed until all the ACs are met. If an AC is not met, this is raised as P1/2 defect (depending on the severity) and linked to the story it affects so that the story is not closed.

All I want, is to see these linked issues in the swimlanes of the Kanban board the same way we do for sub-tasks, as these defects linked to our stories also determine whether the story is blocked or closed. 

We used a couple of the reports built into JIRA mostly to gather metrics around resolution time, how many bugs we expect to raise against a story of a certain point level, what priority level defects are raised at, how many bugs are discovered in production, how many are front-end etc in order to improve our planning, dev and QA processes in future sprints post retro. 

Thanks

Samantha

[SamanthaB]

Not a problem Nic. I think in short, the way I (and my company) want to use JIRA (and something that seems to simple to us) does not seem to be possible to do  Maybe no one else see's a need to link bugs to a story if the problem is found with that story. 

[motherg]

Samantha,

I think your last post has hit the nail on the head, you're doing something really unusual - it sounds very waterfall to me, would that be a fair assessment? Nothing wrong with that, just need to set the way I'm going at the problem.

I'm still not seeing what the issue is with raising the bugs that you have agreed that you must fix for a story to be complete as sub-tasks. Actually, raise alllll the bugs as sub-tasks and then just convert the ones that don't need to be fixed and assign them a priority then?

I'm about to say something that might seem really odd so I apologise in advance. Bug metrics are completely worthless - they lull you in to a false sense that you're improving quality but generally this practice lengthens the value chain and slows down delivery. Raising bugs themselves is a very valuable task, as is resolving them, but if you have loads of them then you can see you need to look at the development practices that lead to that situation. Are there code reviews? Are they good enough? Do you know all the AC's when you start? Do you huddle/power of three when a ticket is picked up? Do you demo back to that huddle before testing starts?

Bugs are very useful (as is tracking them against a feature to make sure they are resolved), metrics on them...not so much.

[Nic Brough -Adaptavist-]

I don't think you're wrong about linking the bug to the stories, when it's appropriate - you're saying "this bug has something to do with this story", it's just that you don't seem to know whether the bug should be part of the story or not.  You're strongly leaning towards it not being part of the story, but then expecting it to partly behave like it is.  Which doesn't make sense to me.

[SamanthaB]

Hi mother-goose,

I think it is fair to say it's more waterfall than agile but I am not sure how else you would raise a bug related to a story (either a defect caused as a result of the change or an AC not being met)? Even though we could raise all bugs as sub-tasks and convert the tasks to bugs if we decide not to work on them, I am worried about the distinction between a bug and a task here to the team. 

Maybe it might be useful for me to know what you would consider the common practice here. Let me provide an example for context.

I have a story:

Test project / Story-1

Add log out button

As a front end user, I want to be able to log out from any page.

GIVEN I am on any page

WHEN I see the page header

AC1:

A 'Log Out' button appears in the top right

AND when selected, the user will be logged out

AND the button state changes to 'Log in'

AND the user is returned to the homepage

Let's pretend I find two bugs with this story:

Bug-1: User is not returned to the homepage 

(and example of an AC not being met which prevents the story from being complete and moved to awaiting approval/done based on the company practices)

Bug-2: The 'Log Out' button does not appear in the mobile version of the header

(not strictly related to the ACs. Browser related issue. Let's pretend there are two versions of the header and the button has not been assigned to the mobile version)

If we have agreed as a company that both issues must be fixed in order for the PO to close the story, how would you raise these bugs?

I originally just wanted to also see these linked bugs in the swimlanes with the stories, but now I am just interested in what you would consider to be the best agile process here when using Jira.

I also agree on your points re documentation. We have code reviews but we have already identified the need for improvement. The ACs are reviewed by the entire scrum team prior ti implementation but sometimes, the devs still miss AC criteria or we find an unexpected error such as bug-2 in the example above. The theory behind these metrics is purely to highlight areas with a high amount of bugs or predict stories which will have a high amount of bugs so we can improve practices and lower risk when accepting stories which high story points into a sprint.

 Thanks

Samantha

[motherg]

Hi Samantha - apologies for the late reply here, yesterday got really busy.

Going with your example I'd raise these as the "dev bug" I mentioned earlier - it's the bug type that we use which happens to be a sub-task issue type. This way it is intrinsically mapped to the feature it belongs to and must be fixed before you go live (according to your DoD).

What I'm saying here is that there is no distinction between a bug that was raised due to a missed AC or a functional issue - they both need to be fixed before you go live, it doesn't shouldn't matter what caused the issue, just that there is one. Having a metric for the number of dev bugs raised in a sprint could be useful - is your team co-located and is the dev and testing done in the same sprint? Sounds like it to me from what you have said - in this instance devs and qa's generally discuss an issue first, sometimes they just fix it on the fly if it's a small problem, other times they may have moved on to another thing so they ask for the qa's to raise it as a dev-bug so they don't have to context switch. The team does have an agreement that if a bug stops the testing of a feature (rather than just being an issue that's been observed but doesn't prevent testing of the feature from continuing) then fixing it is the absolutely priority and they must park the new thing they have picked up.

I'd suggest that you can't really predict where bugs will occur to be honest - you may say an 8 point story is more likely to have an issue than a 2 pointer, but you don't know for sure, it's likely a wasted exercise and could be replaced by something else which would provide you with better opportunities to inspect and adapt.

What do you do with the metrics you gather at the moment? Has anything changed if there are areas of the system that always get loads of bugs? Has the team put more unit/integration tests in that area to help give visibility to breaking changes, or have they just started to size tickets larger?

[Deleted user]

Agree with Nic.

Another alternative would be to use EPICs and define your swim lanes by those. Stories, subtasks and defects assigned to the EPIC would display in the appropriate lane. Of course this comes with some additional overhead.

[SamanthaB]

The problem for this is we have one website project that had multiple EPICs by area (donation, publications, events etc) and each sprint completed against the website project (in particular) may contain multiple EPICs. So we cannot use EPICs to dictate our swimlane content. 

I can understand why it currently works as it does, but it would be more useful if we had the ability to show everything associated to a story in the swimlanes. i.e defects, sub tasks, queries etc as these all need to be completed prior to completing a story. As per regular story definitions and acceptance criteria.