Agile Board Search

brianlan25 · 3 weeks ago

Is there a way to get the search on the sprint planning board to be able to search assigned to? We can search the story number, short description but not assigned to. One of the scrum masters is trying to pull stories from the backlog based on who they are assigned to but has to do it one at a time since they cannot search.

Namita Mishra · 3 weeks ago

Hello @brianlan25 ,

Please see my comments below:

1. "you can no longer drag and drop stories from the backlog to the sprint" - You can do that not by dragging and dropping but by updating the sprint.

2. "It seems the sprint field is not editable in the list view" - It is editable, please refer to the the video.

This would not require opening each and every story to update the sprint field rather you can update the sprint field from the list view; you can also bulk update the sprint filed for the selected stories from the list view.

Hope this answers the above two points and if it does please mark the response as correct to help me and other community members.

Happy SPM Journey!!

Thank You!

Namita Mishra

View solution in original post

lauri457 · 2 weeks ago

There is a script include SprintPlanningMetaDataService that is used to return the config for the board. On Line 77 you can edit the array of fields for the filter

  var searchFilterFields = ['short_description', 'number'];

You can also just treat the search like you are writing a query fragment like so:

^assigned_to.nameSTARTSWITHS

it will work because of the way the app handles the search

brianlan25 · 2 weeks ago

Thanks for the info but we try to start out of the box. I'm not sure I fully understand your section option but that seems like it would be a little complicated for a product manager who also act as the scrum master.

lauri457 · 2 weeks ago

It's of course your platform so you do you but the staying oob concept is becoming a bit of a meme at this stage. Both on the community and out there in the wild. You didn't ask and might not be interested but I'm just giving my take on that here anyway. The idea of avoiding customization to artefacts is so that you generally stay aligned with the intended data model (so you can potentially be sold more product), keep getting updates ie. new features and fixes and won't have to open support tickets, don't create badwill by complaining about the crappy saas product etc etc. The configurability is a big part of why servicenow became so big one could argue.

In my opinion this push for "oob" and having a limit on custom tables causes devs to often create janky and hacky workarounds to achieve certain otherwise sensible requirements.

As for this particular piece of code change, agile2.0 is getting old and I didn't check but probably hasn't seen many significant updates in a while. It is even scheduled for deprecation so if you plan to keep using it, it will ultimately end up as being owned by you. What I'm saying is that categorically avoiding changing something oob is not bad you just need to think of the cost to benefit ratio. In this case it's a line of code to track in upgrades vs a happy scrum master.

The workaround is just a treating the search like an encoded query. It gets appended to the table api call url params as is

https://z.service-now.com/api/now/table/rm_story?sysparm_query=ORDERBYglobal_rank^sys_class_name=rm_story^active=true^sprintISEMPTY^assignment_group=e0bc4264831f3a10557ff0d6feaad3c1
^short_descriptionLIKE^assigned_to.nameLIKEad
^ORnumberLIKE^assigned_to.nameLIKEad^short_descriptionLIKE^assigned_to.nameLIKEad
^ORnumberLIKE^assigned_to.nameLIKEad

Doubt you'll have much luck with the idea submission