6

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

1
  • 1
    Is JIRA so heavyweighted you cannot just enter this description as a new issue in less than a minute? Sounds more like a tool problem.
    – Doc Brown
    Sep 5 '16 at 15:37
7

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.

4

Its probably a change to an existing user story.

ie.

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

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 this!!"

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

2
  • To make change requests like this explicit in the past, I've both changed the original story, and added a sub-task documenting the little job that needed doing.
    – Andy Hunt
    Sep 5 '16 at 14:04
  • 2
    changing the original story is problematic if its already been completed. best to add a new task, but include the full story
    – Ewan
    Sep 5 '16 at 14:06
1

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

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.

-4

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 (http://agilemanifesto.org/)

8
  • 1
    If you don't track it, you forget it. Oh and the correct text in the UI is not documentation.
    – Bent
    Sep 5 '16 at 13:59
  • @Bent forget to do it? you are right, I've edited my answer. My original intention was to express that having thousands of wording-issues in Jira won't be helpful either.
    – Andy
    Sep 5 '16 at 14:12
  • i think it would be very helpful. it shows how much time you spend changing the wording and hence why the project has been delayed
    – Ewan
    Sep 5 '16 at 14:13
  • the PO can sit right next to the developer telling her... -- that's the best known way to kill the productivity, see eg DON'T WAKE UP THE PROGRAMMER! "How about I ask you what time it is sometime around three in a morning? Nothing biggie isn't it? Just asked a simple question. I just asked. You just answered and then you can keep sleeping. Not a biggie. Just once in a while I'd ask you something not very difficult to answer. Something like - "Have you checked your E-mail recently?" There is nothing to worry about, just yes or no answer..."
    – gnat
    Sep 5 '16 at 14:20
  • @gnat did you ever do pair programming?
    – Andy
    Sep 5 '16 at 14:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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