Trying to generate a 5% sample size.

[Manav Shah]

We have two projects A and B. In project A data will be added, project B is quality check. I want 5% of tickets from project A to enter project B for quality checks once ticket is closed in project A. I have created the below rule, please advice me if this is going to work. I have created branch because I need different % of samples for different conditions. Please advice me on variable and its comparison. 

[Stephen Wright _Elabor8_ · Accepted solution]

Hi @Manav Shah 

I assume you're trying to use the logic in this answer?

If yes, it's not an exact science - you're effectively giving the rule a 5% chance of passing the condition, but it's not a guarantee that it'll be 5% exactly.

I also don't think you need to use "Lookup Issues" for this, as it's not based on a set of data, but each single issue's transition.

---

The rule might look like this (without additional conditions)...

• Trigger: Issue transitioned
• Action: Create variable
  • Name = RandomNumber
  • Smart value = {{#=}}CEILING(RANDOM()*20){{/}}
• Condition: {{smart values}} condition
  • First value = {{RandomNumber}}
  • Condition = greater than
  • Second value = 19
• Action: Create Issue

^ So essentially, a random number is assigned between 1-20. And the condition then checks it's over 19 (i.e 20) - which has a ~5% chance of being assigned.

Ste

[Manav Shah]

Hey @Stephen Wright _Elabor8_! Yes figured this one out. But the problem in this rule is that its just a 5% probability and not really 5% of total population is being generated as sample. Looking for further solutions to this problem. Thanks anyways, cheers! 

[Stephen Wright _Elabor8_]

Hi @Manav Shah 

You mention below you already have 1,000 tickets - could you...

1. Use Automation to populate them with a piece of metadata, using the 5% option above, and then...
2. Use a second rule to create a set of issues based on that metadata.

...?

This would allow you to apply the logic to the whole data set and continue to use that logic ongoing with the previous rule above.

----

The additional rule for (1) might look like this...

• Trigger: Scheduled
  • Run a JQL search = TRUE
    
    • JQL - project = Project A
• Action: Create variable
  • Name = RandomNumber
  • Smart value = {{#=}}CEILING(RANDOM()*20){{/}}
• Condition: {{smart values}} condition
  • First value = {{RandomNumber}}
  • Condition = greater than
  • Second value = 19
• Action: Edit Issue
  • Field = Labels
    • Value = <insert value here>

---

A few notes...

• This is an example rule; you could set the "Edit Issue" action to modify whichever unique identifier is best for you.
• You only need to run this rule once, then deactivate it. You can run a scheduled rule out of cycle once it's active. Select the breadcrumbs (...) in the top-right, then select Run rule.

---

Let us know your thoughts :)

Ste

[Manav Shah]

So actually, we have continuous data actually. I just gave an example of 1000 entries to showcase the large dataset size. 

I don't think the above will work for daily tickets, this is more for if you are running the rule once 1000 entries are done. I hope I got your POV right. 

[Walter Buggenhout]

Hi @Manav Shah and welcome to the Community!

That looks quite spectacular. But I am not sure what you are actually trying to achieve as a result.

At a certain point in your automation rule, you suddenly refer to lookupIssues, but I don't see any point in your automation rule where you perform the lookup Issues action. If you don't perform a lookup of a set of issues first, the {{lookupIssues}} smart value will just return nothing. So no, I don't think this is going to work.

If I understand what you are trying to do (randomly generating a number of issues for testing based on an unknown number of issues in another project that might be ready to test) I can't think of a way to automate this. It would be much easier if you could build a ready to test status into the workflow of your Project A, you can easily select the issues that need to be reviewed one by one, thus drastically reducing complexity.

Hope this helps!

[Manav Shah]

Hi @Walter Buggenhout, thank you very much for the quick response. I am quite new here. I just wanted to create a random sample which is almost equal to 5%. How about if I replace my variable to "{{#=}}CEILING(RANDOM()*100" and change the condition to if variable is less than 5, it should create new ticket in project B? 

[Walter Buggenhout]

You can create a new ticket in project B at any time, @Manav Shah. But I don't think that is what you are trying to do, unless I am missing your point.

I understand that you are trying to determine how many tickets should be (randomly) tested. I don't see the point in that unless you also define which tickets these are. And - if you don't define those tickets - why even bother to do all the math? I don't see any place in your rule where you are actually doing something with the result of your calculation.

But, I'm quite sure that's because I don't understand what it really is you are trying to do. 

[Manav Shah]

So basically, my project A is purely a project to input data in CRM based on the description of the ticket. While in project B, I want to quality check these tickets if data is correctly entered based on description once the ticket is closed. But, now there 1000 tickets, I want to quality check only 50 of them as a sample. So, end result of this rule is to create 50 tickets for quality check in project B as 5% sample from project B. 

Just fyi, we don't want to merge both projects, need it separate.

@Walter Buggenhout 

[Walter Buggenhout]

Yes, that seems to be very much what I understood. To give you my very honest feedback: I don't see any point in that. If you are only going to randomly quality check 5% of the input you do in the CRM system, how is that going to even have an impact on your data quality?

That sample is too small to be representative; if you happen to catch no errors at all, you may have the impression that everything is fine, but you don't check 95% of the input. If you find 30 errors in your sample check, you may draw the conclusion that everything needs to be reviewed and spend a lot of time on it, maybe to find out that by sheer (bad) luck you randomly selected nearly all the inputs that had errors.

You may be better of - and create less overhead - to create a JQL filter listing all issues in your project A that were resolved over the last week. And then, simply looking at the number of issues in the list - randomly pick a few to check. You will be able to do exactly the same thing, but you won't have to try building something that is not technically possible.