Skip to main content

Hard to manage user Stories/Tickets because the completion can take up to 2 sprints!

Last post 10:22 am June 3, 2024 by Balaji Dhamodaran
5 replies
06:35 pm May 30, 2024

I work for a US-based grocery company on the B2B integration team, mainly consisting of developers with varying tech expertise. Our work falls into two categories: system development/enhancements and client requests for B2B setups and Managed File Transfers (MFT). Our velocity is hampered by client requests. These are generally easy but unpredictable due to blockers like incomplete information from clients or delays in their development/testing. While our team is organized and manages tickets well, it's hard to capture everything in JIRA and provide the metrics senior leadership wants. I'm considering Kanban but doubt it will solve the problem. Any thoughts?


07:18 pm May 30, 2024

How is the team currently refining the incoming work on the Product Backlog?

It sounds as though it is not in a "ready" state for Sprint Planning in Scrum, nor that it could reach a commitment point in Kanban.


08:58 pm May 30, 2024

We mark the user stories as "ready" once they provided everything that we need (connection details, NDA, etc.) However, in the middle of development the issues that I mentioned arises. Sometimes even the client de-prioritizes the integration and there's nothing that we can do about that. What we can do is take in new requests which we don't have any lack of.

10:13 pm May 31, 2024

These are generally easy but unpredictable due to blockers like incomplete information from clients or delays in their development/testing. 

Why is the client development/testing included in your Definition of Done?  Are you delivering work that meets the specifications that you have discussed with the client in a Sprint?  Create your Definition of Done so that it does not require client validation. At most they will have to wait for another Sprint to get any revisions that they ask for and it will probably fit into their "delay". 

The commitment for a Sprint is to the Sprint Goal not to a set of tickets selected in Jira. The tickets can, and in most cases I've seen will, change during the Sprint as more is learned due to the work being done.  Stop worrying so much about how many tickets your Developers mark as "done" (i.e. velocity) and focus on the value that you are delivering to the clients in each Sprint.  Are you delivering usable increments of Product updates in each Sprint? That is what is most important, not how many tickets you mark as "done" or "closed" in Jira.

...provide the metrics senior leadership wants.

Then maybe it is time to work with senior leadership to help them understand what kind of metrics make sense to be generated.  Generating graphs/charts of how many Jira tickets are being "done" in Sprints tells nothing about the value and quality of the work being delivered to the client.  I suggest you check out the Evidence-Based Management Guide offered here on It might be a good starting point for you. 

06:47 am June 3, 2024

Hi Marvin,

If I understand you correctly you have two workstreams and one team that works on both.

  1. Enhancements /Changes 
  2. Client requests

I have worked in this kind of scenario and came across the same issue that you mentioned where client request takes up sometime and Changes are not completed at the end of the sprint.

My suggestion would be to use Kanban for client request part as they are of add-hoc nature, and it is best to keep this out of the sprint (let sprint backlog be only enhancements and any bugs related to them). Let client request tickets be reported separately like how many requests you solved in a week/month. Have a look at metrics like cycle time, lead time. The enhancements reporting would be based on sprint metrics. Again, discuss with your management and finalize on this.

In my previous experience we had done something like this -every sprint one person (some senior developer) would look at client requests and would not be an active contributor on the sprint. His primary work would be client request, but he would assist in the sprint by doing some Testing/code review when required. 

You will have to figure out with your team, how you would want to handle this and then make the suggestion to the management so that all are aligned with the approach. But my suggestion is to not mix-up client request with Enhancements.

10:22 am June 3, 2024

Our velocity is hampered by client requests.

Kanban method also encourages the "Pull" approach than "Push" approach in taking the work. But in a timeboxed sprints and planned backlogs, the adhoc client requests also should be filtered. Not all the request could be "pulled" in a sprint because it is simple and ready, but its priority needs to be checked. If the tickets are added/dropped in the middle of the sprint and if that impacts the sprint goal that is planned for the sprint, then PO can check if some requests can wait for later sprints.

While our team is organized and manages tickets well, it's hard to capture everything in JIRA and provide the metrics senior leadership wants

Using kanban board is a good idea for "Transparency" about work in progress and identify if there is inefficiency in the way the tasks are handled by the team. How the team is manages the tickets well while they are not able to capture what they do ?. Why the team wants to take work which is beyond visualising it ? imo, This also a problem of no proper prioritisation. PO plays major role in the effectiveness of the team.

Can you make it visible the problem of no proper prioritisation, readiness, and sizing in your kanban board and metrics ? 

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.