Can I search history of story points?

Question

I am attempting to determine the size of a team's backlog over time but I have not been able to figure out how to search the history of the Story Points field.

Search goals: Able to see sum of story points in the backlog on a specific date. This will allow me to track patterns over time.

Unable to figure out how to get these results using JIRA/SCriptRunner queries or JIRA/Dataplane reports. Wanted to see if anyone knew how to find story points over time.

Sharon King · Answer

@Beta Hampton Upon further reflection, have you considered running a (fake) sprint in parallel with the active sprint? This may assist with enforcing the behaviour of planning stories in advance for future sprints.

This discussion may provide further insight: 
https://community.atlassian.com/t5/Jira-Software-questions/Add-a-backlog-space-for-groomed-tasks/qaq-p/1121801

Also see this for possible triggers to inspire the use of Jira to assist in solving your issue at hand:
https://www.atlassian.com/blog/jira-software/groom-backlog-like-boss-jira-software?_ga=2.191476202.1973166972.1589866046-1078883496.1588750722

Good luck.

Sharon King · Answer

Thanks for taking the time to explain. That does make more sense behind your need to track this. 
Typically, this is managed by driving the behavior of the team responsible for maintaining the backlog.  Regular planning with the product owner, helps with preparing the readiness of enough items to potentially fill the upcoming sprint.

Best practice is to have additional items in your backlog also ready to allow for pulling in items as needed if your capacity during estimation allows, or for the event where a story is deemed "un-estimatable" due to not having enough information (as an example).  In this scenario the item is removed from the plan and easily swapped for another ready in the backlog. 
The number of additional, ready items is an expectation pre-determined for each team to have ready.  Regular grooming of the backlog assists in driving this behaviour. The output which is a prioritized back log with a set number of items readily available for the team to pull from (usually) at least a sprints worth in advance of the one to be started.  At a minimum, rule of thumb is for the top 5-10 prioritized items meeting the definition of ready for estimation.

Estimating in advance may assist in driving this behaviour. I would suggest being mindful of this needing the input of the entire delivery team. Meaning its an additional event required during a sprint cycle that may interfere with team's ability to deliver on their sprint goal.  A more efficient way, perhaps is to set the expectation with regards to the backlog, so that all teams have a shared understanding. Then monitor this through coaching (of the guilty teams) so that the practice becomes common for all teams.

Hope this helps.

Beta Hampton · Answer

We assign story points in backlog refinement every sprint for future sprints. During planning we can update those if needed before starting the next sprint. These question is about refinement of backlog items. I

am trying to get a sense of which teams are striking the right balance on how much work to refine and put a story point on. I am seeing some teams have nothing extra ready and others with 5 or more sprints worth of work refined.

Hopefully by tracking this we can help coach teams to balance their refinement to ensure teams have between 1-3 sprints worth of work refined. Does that make sense?

I know its not a common thing to track, but we think there is value in it. We are still newer in properly following scrum/agile at my company and we think this is a good way to see if teams are approaching refinement well.