How do I track tiny/small UI change requests in Agile?

How should I track requests for very small changes in the user interface of my Agile project?

These changes will take very little time to complete and require only a few words to specify. However, they have originated with the customer, and it is therefore very important that they are not overlooked. Creating a ‘User Story’ seems too heavy handed for very small and isolated changes like this. A ‘Task’ doesn’t seem right as the origin is not internal. A ‘Bug’ would imply unintentional behaviour to be corrected.

Example request: “In the membership status screen, please change the word ‘Resigned’ to ‘Cancelled'”.

(We are using JIRA.)


Problems like these are what your retrospectives are for, because there is no “one true agile way” that will work best for everyone in the world, or even every team in a company. Brainstorm some solutions, agree to try one for an iteration or two, then evaluate how it’s going at the next retrospective and make adjustments.

Were I sitting in on your retrospective, I would probably suggest creating one user story per iteration to hold all the minor UI changes, as that would address both the need to track it and the desire to make it a non-trivial size. There would be discussion about it. Maybe there are concerns to address. Maybe some team members would prefer one story per change, even though it would be exceedingly small. Maybe my idea would spark an even better idea. Your team can figure it out. I’ve seen it happen dozens of times.

Its probably a change to an existing user story.


as a user
given I have some memberships
when click on the resign button
the status should read 'cancelled'
and an email should be sent

User stories can be very small. Don’t skimp on tracking stuff or it will just be raised as a bug in QA

“i tested the page and it says cancelled instead of resigned as per
the design”

Or missed all together

“i asked for that word to be changed and you forgot! I’m not paying for

However, don’t edit Tasks which have already been started. You will lose progress tracking and cause problems by effectively creating bugs because the task was different when completed.

Its best to make a new task for the amended user story. include the full (new) user story in the task. keep track of “what i would currently like the end product to be” seperately


The simplest approach with the least overhead and most transparency is to create a story that is nothing but “fix UI bugs”. You can list a specific number of bugs that goes to the story so that it’s clear when the story is complete.

This approach has the following advantages:

  1. very little overhead.
  2. it keeps the number of small bugs under control (ie: you don’t have a mountain of small bugs to fix after all of the stories are complete)
  3. it provides transparency into the amount of effort required for bugs that are introduced
  4. it provides insight into how much time is actually spent fixing bugs.

How we deal with it in Jira; and to extend on what Karl Bielefeldt touched in his answer.

In our retrospectives we decided to handle anything small that is “unexpected” (not part of SP1 or SP2 commitments) as unplanned. We do not size unplanned work. We create a task in Jira so we can make the subject more technical and less “As a …”, and then drag it into the sprint.

Not sizing them helps not making the burn-down look like an echisketch, but we can show in sprint review sessions how many unplanned (unsized) stories were brought in, and then we could discuss any possible influence they may have had on the commitment.

To repeat, all this was decided by our team in a retrospective, and again as Karl mentioned, it can differ between teams.

If it is really small changes like wording, it can also be undone quite easily, so I don’t see the need to track them rigorously. There could be a story accumulating many similar changes, and/or the PO can sit right next to the developer telling her what to change (the commits will reference that one story).

Another answer could be: Agile Software Development prefers working software over documentation (


Trả lời

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *