Improve performance of feature X - should that be a new user story or something else?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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).