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

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Backlog Management & Client Feature Request Tracking

I have a scenario that I don't believe is unique, but I've never seen a good solution for it. I'm hoping one of you more experienced product owners/managers may have some ideas and/or working solutions. Here's my scenario:

  • We have a product that we develop for a paying client, and we have a single project in Jira where we maintain/manage the backlog for that product - both the must-have MVP features (we have yet to launch) plus future nice-to-have features to potentially work (and bill for) on post-launch
  • In order to answer the client's questions such as what is the defined MVP feature list, where does each feature currently stand, etc., we moved to a very epic-heavy approach and created an epic workflow to track features from initiation to estimating to approval to in-progress and on until it is released to production; VERY effective and we show all these steps in summarized columns on a Kanban board, but it has inherent problems, such as...
  • Epics don't show up in the backlog where they can be prioritized along with one-off stories and the team can see them rise to the top and then eventually pull them into the next sprint (the first few stories for that epic, that is)
  • One-off stories for little things that can be completed in a single sprint get lost or overlooked when such focus is being placed on the higher-level epics/features -- those epics being managed somewhere other than the backlog (Kanban board)
  • And we end up with a large number of open epics that team members need to sort through in order to find the correct one to link new stories to (the closed ones go away, but all the open ones that are in the early stages of the epic workflow appear...yet the team may not even know what some of those are in such early stages); epic link is one of our few required fields in order to maintain some sense of organization, but open to changing this

The short-term fix that I've thought of is to simply create a separate project to maintain ALL epics and stories that have not yet been approved by the client to be worked on (we may have some one-off stories that don't require client approval and we want the team to be able to pick those up whenever and work on them, but don't want to implement a story-level workflow that is as cumbersome as our epics workflow). But surely someone has thought of a better way to manage a scenario similar to this while keeping everything in the same backlog. Has anyone experienced a similar scenario and have any suggestions on a best-practice approach? My main objectives are:

  1. Be able to clearly track and report on client-requested features, whether they are expected to take 1 sprint (story) or multiple sprints (epics) to complete
  2. Make it clear to the team what is okay to pro-actively pick-up and work on versus what requires specific approval from the client (due to various billing scenarios, etc.)
  3. Make this whole process user-friendly and efficient for anyone working within or reporting out of Jira for a specific product

Thanks in advance for any feedback!



Log in or Sign up to comment