nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Adding Column in Backlog for "Analysis completed"

Clay Nichols_0kvygj

Our Developers and Project Managers both have indicated that sometimes (1/3 to 1/2) Jira tickets do not include sufficient analysis.

It seems like the Lead Developer is the best person to confirm this.

My first thought was to essentially add an "acceptance test" for accepting Issues onto a Sprint. So the Lead Dev would take a look at each Issue, confirm that it's got sufficient analysis and then move it into Todo. If it's not sufficiently "analyzed" then they'd kick it back to whoever created the Issue for clarification.

Any thoughts on this?

Where should this go?

New column on Sprint board? New column in the Backlog?

Comments

Trudy P Claspill

Hello @Clay Nichols

Are you working with a Company Managed project or a Team Managed project?

Do all issues require this review? Are you expecting the Lead Developer to do this evaluation alone for all issues? In the scrum teams I've been on, we used our Backlog Grooming meetings to do this evaluation, and also to assign estimates to the work.

How do you want to make sure that review is being completed? You could add a custom field to track that the review has been done.

What I have done in cases like this is add a faux sprint on the Backlog screen, and I never start that sprint. It is just a bucket for the issues that have been reviewed and are deemed ready to be added to a sprint. You might call it "Groomed Issues" or "Ready for Sprint". When you are planning your sprints, you then populate them from the issues in that faux sprint, rather than from the issues in the Backlog section of the list.

Adding a status to your workflow is another way to handle this. Note though that in Scrum boards there is no distinction between Backlog and in a Sprint based on Status. If you wanted to enforce that the issues got reviewed before being available for adding to a sprint, then you might consider having 2 boards. One board would list only the issue in their initial status immediately after creation (i.e. To Do). The only purpose for that board would be segregating the issues that have not been reviewed for sufficient analysis. Your primary Scrum board would include all the other Statuses for your issues, where your "Reviewed/Ready for Sprint" status would become the first status of your board. In that manner you could ensure that only issues that had been reviewed and transitioned to your "Reviewed/Ready for Sprint" status would be available for adding to your sprints.

Either of these works reasonably well if it is your intention to evaluate the issues before they get assigned to a sprint.

Clay Nichols_0kvygj

All issues need to be confirmed that IF the analysis was needed, that it was done. I.e., we don't know which issues need analysis ahead of time
Yes, Lead dev will be the only one confirming "Was analysis sufficient"? for each Ticket doing to his devs

Ok, so you're suggestion this possible implementations:

Add a custom field "Analysis Verified by Team Lead
Add an additional Status (same title).
Create a "dummy" Scrum board for kinda pre-stating the Issues.

#2 Might be easier to track in metrics (how often do Issues get sent back for more analysis)

That sound about right?

Trudy P Claspill

You've added new requirements/factors

- not all issues may need analysis, so you need to be able to specify if the analysis is needed.

- you want to report on how many issues "go back for analysis", which implies that perhaps the determination for needing analysis may not happen before the issue goes into a sprint

I think you need to first clarify for yourselves what the actual or desired process flow is with its requirements for transitions from one step to the next.

There are a lot of ways this could be done depending on

- your desired process

- how you want to be be able to segregate issues needing/not needing analysis

- how you want to segregate issues where the needed analysis has/has not been completed

- how strictly you want to enforce the process

- what reporting you want to do on the process

There are options for using custom fields, statuses, multiple boards, swimlanes (if you don't have other requirements for swimlanes), and workflows.

The options are also impacted by whether you are using a Company Managed project or a Team Managed project.

The simplest solution might be to have a status for "Analysis Needed". Have that as your first status for newly created issues. Assume Analysis is needed until it is determined that it is not. When you determine the analysis isn't needed, or is complete, move it to the next status that is an indicator it is ready for assignment to a sprint or ready for work in a sprint to which it is already assigned. Have all the statuses on just one Scrum board so that if a issue in an Active sprint is determined to need more analysis, it can be moved to the Analysis Needed status while remaining on the board. You would be able to report on issues that "go back" using a CHANGED or WAS JQL operators.

https://support.atlassian.com/jira-software-cloud/docs/advanced-search-reference-jql-operators/

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud