Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Mark Issues to Refine in Jira Agile

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.

2 answers

1 accepted

1 vote
Answer accepted

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

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

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

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

Thanks,
Fabian

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

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 (skull.png) 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

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.

Suggest an answer

Log in or Sign up to answer
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you