Mark Issues to Refine in Jira Agile

[Fabian Ehrentraud]

How should we mark Issues which should be refined in the board?

At the moment we have a "Refinement" sprint at the end where all issues are collected that need to be refined before being ready.

Problem with this approach: When creating a new sprint, it gets added to the board at the bottom below this refinement helper sprint, and I cannot move it above. Each time I need to move all issues of the old refinement sprint to the new one below, rename the sprint names, and then can fill up the real sprint.

[Kim Poulsen · Accepted solution]

Hi Fabian

For sure I think you should reevaluate your use of the planning mode. Usually the top of the backlog is what is/need refinement, so planning sprints ahead should be a matter of slicing the backlog from the top down.

We help ourselves sorting out what part of the backlog we have already refined and what part is the next bit to refine by adding a few new states to the default workflow:

Open -> Grooming -> Ready -> In progress -> Resolved/Closed

We also have a "Need Info" state which issues in grooming can transition in and out of while it is worked on for getting it ready for sprinting.

Using quick filters it is then possible to show only the issues which are in "Grooming".

Actually we have two boards, one that maps the states prior to "Ready" and one mapping from "Ready" and onwards.

Maybe you can use something like this at your end.

BR. Kim

[Fabian Ehrentraud]

Thanks for your insight, Kim. This seems like a workable solution, I'll definitely discuss this with our Scrum Teams.

A question to you workflow: you do not seem to have a separate QA state. How do you proceed with issues that are implemented, but not yet exploratively tested?

Thank you,

Fabian

[Kim Poulsen]

We handle this is two ways:

1. Our Definition of Done includes design, implementation and verification. I.e. a story is not done if it is not verified.

2. If a story is decided (typically by the PO) to be okay for closing, i.e. the project accepts the technical debt and increased risk, we must generate a technical debt story to show this decision.

We could have had a separate QA state but I think we would be borderlining sc-waterfall-rum if you get my drift. As a Scrummaster I will not communicate in a workflow that we can accept handovers to e.g. a QA team. I want the QA-function within my team.

Also we try to keep things as simple as possible. My general feeling is that people want to spend less time reporting to a tool what they are doing and more time just doing. With that in mind we have as few states as possible and incourage using broadband communication channels like the daily standup and walk-and-talk.

Best regards,
Kim

[Fabian Ehrentraud]

These ideas resonate a lot with my impressions. I think the idea of technical debt stories is very interesting.

Thanks,
Fabian

[Monika Gottwald]

Thanks a lot for sharing your ideas.

On my side we are discussing "technical debt storys" as well. How do you separate "User Storys" from such other storys? How do you make the difference visible e. g. in Backlog?

Regards,

Monika

[Kim Poulsen]

In our case, and to send a clear signal to the organisation, I created a new issue type called "Technical Debt" and I made sure to use a highly visible icon () to get the point across.

  Now, I wrote my original answer 7 years ago, and these days, no-one is interested in creating more of these little fellows.  Rather projects seems more interested in finishing what was started.  Which is good.  One of the projects I was on had at the time about 25-30% of this issue type filling up the backlog.

Using a specific issue type for this makes it easy to find everywhere, and for leaders and development teams to make conscious decisions on how to proceed.  Also with the icon in place it becomes a highly undesirable thing to have around for any PO or project leader, because questions will be asked.

(As a side note, I also changed the 'Grooming' state to 'Refine' in accordance with the Scrum Guide.)

Regards,

 Kim

[Marion Rosner]

Hi @Fabian Ehrentraud, I'm probably way too late for this, but what we do is, once an issue is refined and ready to be brought into the sprint, we put an asterisk and a space at the start of the title. When we bring it in, we remove the asterisk and space. Makes it extremely easy to see what's what!

Cheers,

Marion.