We have implemented and closed user story X but found out later that the implementation is too slow and we need to improve performance. I think it was a mistake not to have acceptance criteria for performance in the first place but it happened and the question is what to do now.

We can theoretically do one of these things:

  1. Reopen the user story (we use JIRA and it is technically not a problem), add acceptance criteria and let the development "fix" the software.
  2. Create a new user story, like "make the user experience of feature X smoother".
  3. Create something that is not a user story (in JIRA, probably an issue of type "Task").

Is there a best practice telling what to do in such case?

  • 1
    This isn't an answer to your exact question, but is something that has bit me before when dealing with performance acceptance. In addition to establishing what "fast enough" is, make sure to establish the environment that performance will be tested against and what exactly you are measuring. For example: if it is a web application, you may want to consider whether you are measuring at max simultaneous users (and other things that might impact overall system performance), and whether you are measuring time to first response from the server, time to complete page rendering, or something else.
    – Kyle
    Apr 16, 2012 at 17:07

4 Answers 4


What is technically possible in the tool is not so important here. I personally use the following rules regarding such cases:

  • If such issue is found during the sprint/iteration/before the official demo of a story, then I just use a simple task or comment for a story as the work is still in progress.
  • If the story is done and has been accepted then it is already a past. I don't update such stories. It's like it was on my board one day, but has already been put into the trash bin. I simply create another story.

In this case it can simply look like "As a user I want feature X to be faster, so that I don't loose my time to do the job that brings me some value". I don't believe that performance improvements do not provide value. If they don't then you actually do not care about performance.

In case such an issue is a bug (but I would not treat this case as a bug), you can decide if the bug is big enough that it deserves a story or if you can just put it as a task in some shared story called for example "Bug fixing". But bugs are just another story.

If you do not follow iterative development, but rather some kanban-like method, then I would imagine that there will be some point/state in your flow where you do not move the cards back (like deployed or accepted already).

I would agree with @Paweł Brodziński that you may consider adding performance considerations to your definition of done, but as you say you don't plan to test performance for each story, you may just treat such cases as stories.

  • Thanks it makes sense. As we are closer to Kanban than other iterative methods, I think we might consider abandoning the notion of user stories vs. tasks entirely - after all, all we just need is a prioritized pile of stuff to do and it doesn't really matter if it's labeled user story or task in our issue tracking system. Apr 16, 2012 at 17:43

You are already working with user stories and tasks. Normally user stories represent business requirements and they come from business. Each user story consists out of one or more tasks. Each task should take no longer than a day (our tasks normally take between 30 minutes and 4 hours), otherwise it needs to be broken down into smaller tasks.

I'm assuming that your initial user story was to develop a feature. You've met business requirement by developing that feature. The feature went live. Now business wants to make improvements to the feature by optimising its performance. This is a new user story (requirement) from the business perspective. Just like any requirement, it needs to be analysed and tasked up.

I think that you should not re-open an existing user story. It's easy to do and it will cause problems further down the line. At what point are you going to say that it's enough and it's time to create a new user story?

Performance improvements can go on for months. You might be optimising your framework, front-end site or database access. If this is likely to be an ongoing task, then I would create an epic story for performance improvements. I would then create a new story each time I want to make an improvement in some part of a system.

I strongly believe that task should be always linked to a user story. If you are working on a task that doesn't belong to a user story, then you are working on something that business didn't ask you to do. You can make rare exceptions if the task takes less than 15-30 minutes.

  • So how about creating a task called "improve performance of feature X" and link it to the original user story? JIRA technically supports that, I'm just not sure if this is the right way to do things. Apr 16, 2012 at 16:34
  • 1
    Tasks are normally small units of work. What if your performance optimisation takes over six hours? Once this happens it's a good idea to break it down into further tasks, otherwise it'll become unmanageable. Main point that I'm trying to make is that your optimisation requirement came from business and that's normally a user story. This story needs to be analysed and broken down into separate tasks.
    – CodeWorks
    Apr 16, 2012 at 17:08

First, ask yourself whether this situation is common or it happened for the first time and you don't expect it to happen more often than very, very rarely.

If this is just a rare special case you can do pretty much anything as long as you fix the problem. No need to introduce specific rules to handle such situation. We can totally leave special cases as they are - special. If they start happening every now and they you can come back to the problem and find a systemic solution.

Considering you want to have some sort of standard way of dealing with such cases think of a way that would eventually show how things really looked like when you analyze historical data in future.

My preferable way of doing things would be reopening the ticket/index card as eventually you would be able to update any data you gather (completion time, time spent, etc.)

If you go with a separate ticket eventually you may treat it as another regular user story instead of a special case.

If you decide to add a different type of task don't forget to update user story with any relevant information.

And finally don't forget to ask yourself (I mean the whole team) why it happened that the story isn't done and what you want to do with your definition of done against future stories. In fact this is way more important than sorting Jira tickets out.

  • The story was considered done under original criteria (we don't do performance testing as an integral part of our process and I don't think we are going to change that any time soon) and only later, when it was revealed, I was wondering what to do. Maybe it should be treated as a bug which begs another question, whether to treat bugs as user stories but that would be another question. Apr 16, 2012 at 16:31

What I suggest the team to do is:

  1. What is the objective of the original story? -> a functional feature (no mention or performance). If that is delivered, the story is closed.

  2. If performance was not considered (in the user story and the development of the story), then it's an enhancement of the feature, so it becomes a new story: "As a user, I'd like for the page to load in 5s".

  3. I always like to create a new story also to simplify the velocity calculation. Why? -I have a user story of 10 and I deliver it -the feature is functional but performance is low (so let's say the team decides they delivered 7 points) -then the remaining 3 points need to be transferred in the following sprint (re-opening the story, re-assessing and so on).

^the process is too complex. To simplify, I just create a new story. It also affects the mood of the programmer - because he sees his work done (even if deployed on staging only), checking up a story as done gives you a psychological boost. So you create the impression of moving forward overall.

TL;DR: create a new story, increasing performance is an enhancement of a feature, can be a new story entirely (as a user, I want my page to load in 4 seconds).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.