Review customer requests, merge matching ideas and clarify the requirements. Give your team a prioritized backlog it can discuss, estimate and turn into a release plan.
Refine your product backlogBacklog refinement is the ongoing work of reviewing, clarifying and ordering product backlog items. Backlog grooming is an older name for the same activity. It prepares selected work for a planning decision.
Keep the customer problem, scope, acceptance checks, estimate and dependencies clear. Separate reviewed priorities from requests that still need evidence or clarification.
Acme receives Custom roles in Slack and a Team permissions request through its widget. The team confirms the same need, merges the matching Ideas and refines core roles for paid Acme workspaces.
┌─ READY FOR RELEASE PLANNING ─────┐ │ selected Custom roles │ │ issue ENG-142 │ ├──────────────────────────────────┤ │ Set dates and owners in Gantt │ │ Connect task dependencies │ │ Review the release window │ │ Announce after actual release │ └──────────────────────────────────┘
Bring requests from your widget, conversations and support into one place. Read the actual problem and customer context before deciding that two Ideas are duplicates.
In the sample, Custom roles and Team permissions both ask for configurable teammate access. The SSO request describes a different need and stays separate.
Open the public Idea card, choose Merge ideas and select the Idea that should remain. Voters, votes and tags move to that Idea. The original entries remain listed under Merged ideas, and you can unmerge them.
Keep distinct requirements separate even when the titles look similar. Merging public Ideas is separate from linking them to existing backlog work; it does not merge Jira or Linear issues.
Organize feature requests → · Collect feedback in your product → · Capture Slack requests →
┌─ REVIEW BEFORE MERGING IDEAS ────┐ │ Same need: custom team roles │ │ keep Custom roles │ ├──────────────────────────────────┤ │ Merge reviewed duplicate │ │ Voters, votes and tags move │ │ Keep SSO as a separate idea │ │ Unmerge if the match is wrong │ └──────────────────────────────────┘
Write down who needs the improvement, what they are trying to do and what evidence supports it. Define the scope and the questions you still need to answer.
For Custom roles, the sample scope is core roles for paid Acme workspaces. Acceptance checks include an admin creating a role with chosen permissions, assigning it to a teammate and verifying that the teammate can perform allowed actions while restricted actions remain unavailable. Guest access is out of scope.
Use an Idea template to prompt customers for clearer input. Ask the built-in Ducalis AI chat or your own assistant through cloud MCP to propose a requirements draft from the supplied feedback and source links; your team checks the facts, scope and acceptance checks before using it.
Use Questions when an issue or criterion needs clarification. Discussions are available on the Questions page and in the issue card. Keep unresolved questions visible before treating the work as ready.
Link the reviewed Idea to an existing issue or use + New to create work in Ducalis or your connected tracker. Put the reviewed scope and checks in the issue and retain the link to the customer Idea.
Draft requirements, stories and acceptance criteria with AI → · Configure a request template → · Choose your AI workflow →
┌─ LINK THE REVIEWED REQUEST ──────┐ │ idea Custom roles │ │ issue Linear ENG-142 │ ├──────────────────────────────────┤ │ Link existing or create new │ │ Put scope and checks in issue │ │ Keep the source idea linked │ └──────────────────────────────────┘
Agree on the criterion definitions and rating scales. Assign evaluators with the relevant expertise and compare the refined request with bugs, improvements and other planned work.
Check effort, dependencies and uncertainty for the clarified scope. Use Criteria Alignment and Users Alignment to identify contrasting evaluations, then discuss the assumptions behind them.
Evaluators can revisit their estimates in the issue card. Review Final Scores under your configured permissions and decide what the team is ready to take into work.
A new estimate or a changed scope can change the ranking. Keep the decision rationale with the task and revisit it when new evidence arrives.
Prioritize customer requests and backlog work → · Review team scoring disagreements →
┌─ REVIEW BACKLOG PRIORITIES ──────┐ │ Recalculate configured model │ │ Review ranking and trade-offs │ ├──────────────────────────────────┤ │ selected Custom roles │ │ issue ENG-142 │ │ scope core roles + access │ │ Team agrees what to plan next │ └──────────────────────────────────┘
Prepare a focused set of items and give evaluators time to read the context. Bring the unresolved scope and scoring questions into the discussion.
Choose the items for this refinement cycle, define the criteria and assign evaluators. Product clarifies the outcome; customer-facing teammates supply evidence; engineering reviews effort and dependencies.
Assign users and criteria →Agree an evaluation window. Teammates score their assigned criteria and raise questions. If you use Evaluation Poker, configure private scores until Reveal, then review the results.
Configure Evaluation Poker →Discuss unclear requirements and contrasting estimates, revise scope or scores where needed and review selected work. Repeat refinement as new requests or evidence arrive.
Evaluate and re-evaluate issues →Use this practical checklist for the selected work. Your team defines the readiness standard for its product and release.
| Review area | What the team can explain |
|---|---|
| Customer problem | Who needs the change, why it matters and which source requests support it. |
| Duplicates and links | Matching Ideas have been reviewed; the surviving request is linked to the right work. |
| Requirements | Scope, exclusions, acceptance checks and unresolved questions are visible. |
| Effort and dependencies | The team has reviewed the estimate, uncertainty and work that must happen first. |
| Priority decision | The configured scores and trade-offs have been reviewed; selected work has a clear rationale. |
| Planning input | Selected items are ready for the team to assign dates and owners and review the release window. |
Choose the refined items your team will take into work. For Custom roles, plan access-model changes, the roles interface and release QA in Gantt.
Set dates and owners, connect dependencies and review what fits. If a predecessor takes longer, Finish to Start can shift dependent work and the team reviews the release window.
Choose which customer-facing Ideas to share on the public roadmap. Configure linked issue status rules separately, then review and approve the release announcement when the feature is available.
Plan dates and dependencies → · Show customers the progress → · Publish reviewed release updates →
┌─ REVIEW THE RELEASE PLAN ──────┐ │ scope Custom roles │ │ QA end Oct 30 │ │ target Nov 2 · planned │ ├────────────────────────────────┤ │ Team reviews the new window │ │ Share updated scope + timing │ │ Publish after actual release │ └────────────────────────────────┘
Use a cleanup playbook and checklists to review unclear items and keep the original problem visible.
Review the source, confirm duplicates, clarify the requirements and discuss the priority. Use that decision to prepare your next release plan.
Refine your product backlogUse the refinement checklist → · See the full feedback-to-release workflow →