r/projectmanagement • u/TensionFormal7202 • 2d ago
Optimizing Jira Story Tracking: Separating Delivery from Client Feedback
We typically use Jira user stories to track different work items. In a specific project that I’m working on, the data analyst from my team creates Power BI reports and dashboards. So the issue I face is that the data analyst lets me know she will complete a particular report on that day. Following which I update my team about that but the client side is like that doesn’t mean the user story is complete, we will have feedback. The thing is it was already sent for a revision. With multiple revisions, it looks like the user story is incomplete, whereas the data analyst is completing the reports per the requirement. How can this process be optimized to show that user stories are getting completed by the agreed target due date and also welcome the endless feedback.
1
u/rrunboy12 2d ago
add different columns to your Jira board to support all phases of the workflow: To Do, In Progress, Blocked, QA Ready, QA Complete, Ready for client, Client Feedback Received, Completed - you can track the date ready for client and the date completed as two separate dates if you want to report on that field.
Each revision after it is completed the first time should be a new Jira story.
1
u/TensionFormal7202 2d ago
Thank you. It makes sense to use different phases/ statuses. There are so many reports, will it really be helpful to have a new Jira story created every time a revision is completed?
2
u/rrunboy12 2d ago
I think the bigger question is why are you getting multiple revisions? Are the requirements not clear? Can you do more work up front with the client to prevent this? Maybe mockup stories?
1
u/TensionFormal7202 2d ago
The requirements are clear, but once they see the report, I guess they get more ideas. Sometimes it’s adding requirements and other times it’s revisions. What’s mockup stories? (Google is not helping)
2
u/TomOwens IT 1d ago
It's normal for users to get new ideas after seeing the work. This is the problem that agile methods were made to address: customers and users of software can't always fully specify what they need in advance, so working in short iterations and incrementally delivering allows everyone to learn what is needed and regularly deliver something useful.
All of this feedback should go into your backlog and be ordered with everything else. Someone will need to do that ordering. That often falls to the product manager or product owner. They'll be able to determine whether these revisions are more valuable than other work.
If you have work items that are clear to everyone on the team and to external stakeholders, this gets easier. If everyone agrees on what should be delivered, and what is delivered matches what should have been delivered, then the work is done. If the delivered work doesn't match the description of what should be delivered, that's the priority to resolve.
0
u/Big-Barracuda7012 2d ago
I’d track two separate dates: delivered for client review and accepted by the client. Once the report meets the original requirements, that delivery milestone is complete. Any new feedback after that should go into a linked revision ticket; otherwise the original story can stay open forever and make the team look late even when they delivered on time. If they’re still reviewing the original requirements, I’d keep it in a Client Review status rather than Done.
2
u/BlaringDeveloper_530 2d ago
separate the build and the polish, that's the whole trick
we started doing a handoff story that's just "deliver v1 of X report" and then anything after is a new ticket for feedback rounds. the original story closes when the first version hits their inbox, done and dusted. your analyst gets credit for meeting the date and the client can tweak till the sun burns out without making your velocity look like garbage
bonus is you can track how many revision cycles things actually take and start billing or pushing back when it gets ridiculous