How can I plan optimization tasks in Scrum?

Question

Recently my Scrum team has received several requests for optimizing certain parts of our code. Looking at the software with a profiler found some spots where the code could be improved.

We agreed to plan mostly based on user stories to ensure that everything we do has actual benefit for an end user, but how would this story be phrased? I can't come up with a good wording for them.

How would we best plan such effort? is there a good way of talking about performance optimizations in terms of user stories?

Answer 1

Usually you would create user stories along these lines:

• As a user, I want the transition from X to Y to happen in less than Z seconds.
• As a user, I want X to be responsive.
• As a server administrator, I want our server to be able to handle X simultaneous requests.

Note that the 'user' in user story doesn't always have to be a paying customer. As long as there's a clear benefit to the business, the 'user' can be one of your own staff/departments. If you can't define a clear benefit to the business - i.e. money brought in, or time/money saved - drop it and move on to something else.

Some notes on timings:

• Where possible, it's better to be exact about timings since that removes any potential arguments over whether the changes meet the requirements.
• Timings might be specified relative to previous versions. e.g. "half the time it takes in v1.0".
• Bear in mind the hardware your product runs on will also make a difference! When it isn't implicit, it's worth specifying the target environment for acceptance testing.
• You may want to back up a nebulous requirement with a concrete one for acceptance purposes. e.g. "as fast as possible (but not longer than a minute)".
• When you really can't give an exact value I personally don't have a problem with being inexact ("about a minute", "about half the time it takes in v1.0") or really non-specific ("faster", "as fast as possible").

Answer 2

The decision to word it in user stories is excellent. You've found that if you can't come up with a good story (particuarly the "so that") there may be no value in doing the work?

I agree on making it quantitative, otherwise how can you verify it.

I'd accept these if they reflected the what the users are experiencing:

• "so that I don't get frustrated"
• "so that I half the amount of time doing x"
• "so that I am that little bit happier in the morning"