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.
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.
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?
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.
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!
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs