Why are QE/QA story points a 2nd class citizen in JIRA?

[Jon Thor Austen]

I have worked as a QE for many years on a number of scrum teams using JIRA.  Every time I have been on one of these scrum teams, they have no ability, just on a basic level, in JIRA to track or measure QE work.   As a result, I am in grooming meetings where Devs are planning work and QE gets excluded.   I feel like the main reason for this is that JIRA provides no easy way to deliniate QE/QA work from dev work.

So, I am wondering why this the case is OR what solutions you may have used to get around this?  Perhaps there is a way to solve this currently, but the JIRA administrator just doesn't understand Dev team needs?

Or, is the problem my way of thinking:  wanting to  wrap testing work together with Dev work on a single Story.    Isn't it natural to think this way?   My company wants testing to be part of each story, which is why I find myself needing this approach.   

[Nic Brough -Adaptavist-]

Agile tends to suggest that testing should be part of the team capablity and hence estimated as part of a story.  An estimate of X story points should include the effort needed to create and test the solution to the story.  Because the testing should be part of the story, with test capability in the team, there's no need for a separate QA estimate.

That's the theory.  In real life, people often use separate issues for QA, especially when QA is not part of the scrum team.  I personally prefer to use a sub-task on the story to remind us to test something, but I often see automations used to create and handle testing tasks (whether sub-task or issues in their own right)

[Jon Thor Austen]

Thanks, but my question is more about estimating effort on a story.  There is no mechanism in JIRA, for example,  to mark a QA sub-task as having a point value contributing to the overall story point value.  I think sub-tasks can have a point value, but, for example, that value wont show up in the "Workload by assignee" preview during planning.  See what I mean?  (I realize it may be possible to roll-up points to the story manually, but still only on a 1-user basis, as reported by 'workload by assignee' preview).

The use-case here is a Story, having a point value, where 2 or more people work on it during the workflow,  where the last of those persons, in this case a QE, is working on the story after it has finished achieving its business value, and therefore the QA testing work is often not given additional point value, to the story, as part of its grooming.

I can't possibly be the first person noticing this problem.   Do you see what I mean, that JIRA has no mechanism around this and it forces users of JIRA, to do work arounds like separating QE work into different EPIC-stories or STORY-subtasks.

[yashwanth k]

I am from dev but in my observation, I still see that there is no concrete provision for it neither in Atlassian nor Scrum.

[Nic Brough -Adaptavist-]

Correct, that's because testing should be part of the story's estimate according to Agile.  It's expected that when the team is refining the backlog, the test element should be included in the estimate then.

Note that you don't put estimates on sub-tasks, they're part of the story, not separate items that you commit to delivering.

I've seen a few ways to approach QA and Dev estimates as separate items, and the simplest / best one I've seen for Jira is to have a custom field for each added to the story and then the story points recalulated by a script or automation when they change.  (It gets more complex if you have sub-tasks and put the estimates on those, but you still effectively have to add it up to a total on the story)

[Robyn Cogert]

Having same issue here. We decided to duplicate stories - 1 for QA, 1 for Dev.

The problem I see with the last comment about a custom field to track each on the same story is that Dev completed work before end of sprint, and QA does not so the ticket rolls over and Dev work is not counted for previous sprint.

[Nic Brough -Adaptavist-]

Ok, that's not how Sprints work. You get "counted" when you complete the story, not when bits of it are done.  If an issue rolls over sprints because Dev finishes but QA did not, then the issue was not finished and you don't count any of the effort in the first sprint because you didn't meet your commitment.  Velocity is binary - it is done, or it is not.  The "correct" answer here is that your stories should be estimated to fit within a sprint, and that includes the testing element (and development, and documentation, and all the other things needed to complete the story)

[Marcin Łukaszewski]

The issue still persists.
I can relate to this post in such scenarios:

Let's say scrum team plans their sprint, and gives estimate for a single story (using FIbonacci sequence):

1. Developer gives an estimate of 5 SP, looking at what he/she must do.
2. QE, looking at the same thing, gives an estimate of 8, or even 13 SP.
The result is 13 SP, which seems like a very complicated story, that would take whole sprint to finish.

By using the rule inside my organisation (if SP >=13, story must be split into smaller portions), scrum team would have to split the issue into smaller fragments.
But that results in a lot of smaller tasks, that clutter backlog with how much issues there are.

Should I, as a QE, add my SP to overall SP count to make things happen the way I described it above, or should I have  a separate issues w/separate estimates?
If separate estimates would be the case, how Jira can help in this? 

[Nic Brough -Adaptavist-]

In this case, your story is 18SP (assuming QE selects 13 SP).  If that can't be done in one sprint, then split the story up.  

There is no "clutter" in a backlog, it's intended to be a list of stuff that needs doing.

Remember that it's a single team that needs to deal with this (your developer and QE person are in the same team), so you would want to split it along lines the developer can break it down into discrete parts, and then estimate the smaller stories alongside the QE person.

Or if you have dev and QE in different teams, then it's two stories, one for each team, and I'd simply link the two stories together.

[Marcin Łukaszewski]

I suspected as much, thank you for your answer!