How is the Agile process affected if a stakeholder requests that a specific operation in the software need to perform better?  This could mean that it runs very slow for a customer's needs (even with hardware improvements) or it crashes completely under the demand.How would this affect different parts of the Agile process, including:User/Technical Stories.  Are the User Stories limited to As an end user, I would like part of the software to perform better.?Acceptance Criteria.  What kind of goals should be pursued?Spikes.  Should a developer research that part of the software to try to identify areas of improvement?Sprint Demos.  What is the best way to share performance improvements with the stakeholders?In addition to any other parts of the process that might be treated differently under this request.
How do you handle Performance tasks in Agile?
agile;performance
There are a few different ways that you can handle performance (and, really, any non-functional requirements).If the requirement is known early in the development, make it part of your acceptance criteria or Definition of Done and make sure it stays there. If you have a specific performance requirement, develop tests (preferably automated tests) to ensure that you are hitting the performance metrics. If it's a specific reliability requirement, develop some tests that you can run on a regular are harder to do this with because it's harder to test for them in an automated fashion. Usability requirements that state a particular user class must be able to perform a function in a given period of time, for example. Testability and modifiability requirements are also harder to test, but can be analyzed.If you are making a change to the system, treat it like a user story. This is perfectly valid for new stories as well as instances where functionality has been delivered, but needs to be improved. As a {user class}, I want to {function} in {time} is a valid user story, as would similar stories. It's important to make your requirements specific and measurable, though, so you know when you have achieved them. You can prioritize them in the product backlog, estimate them, and pull them into the iteration just like any other story.Once implemented, you can share the results of your testing at the Sprint Demo, just like any other story. If your requirements are harder to demonstrate (for example, certain up-time), then you can use your test results. Other attributes can be demonstrated, either through using the software or scripts that can drive the functionality.If you need to, you can use a Spike to address these stories or requirements. If you need to do research first, then starting a timeboxed a Spike is the appropriate thing to do. This is useful when you don't know if achieving a particular requirement is feasible or there is insufficient information to estimate and implement. You may not actually solve the issue in the Spike, but you can at least commit to understanding the issue after a period of time and having a conversation with the stakeholder.