Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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.   

1 answer

1 vote

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)

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.

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

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)

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you